Fedora Account System
Red Hat Associate
Red Hat Customer
Dear package maintainer, This is an automated bug created due to a FTBFS when rebuilding this package for the change proposal CMake 4.0. The rebuild is being tracked in https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/package/wsjtx. See https://fedoraproject.org/wiki/Changes/CMake4.0 for more information on how to make the package compatible. More specifically, depending on the state of the project: - If it is actively maintained, please update the `cmake_minimum_required`, and instruct upstream to do so as well. To minimize future maintenance, please add a higher bound as well, preferrably with the highest CMake version being tested. You may use 4.0 as the higher bound as this is being tested in the tracked copr project. - If the project is not maintained, you may add `CMAKE_POLICY_VERSION_MINIMUM=3.5` as a CMake variable or environment variable. You can check the build locally following the instructions in the change proposal, or submit your build to the tracking copr project. Let me know if you encounter any issues, or need any other help.
I was going to take it but I have quite the long list of packages and hadn't quite gotten to it yet :) I've just been using the environment variable method and reporting upstream.
(In reply to Richard Shaw from comment #1) > I was going to take it but I have quite the long list of packages and hadn't > quite gotten to it yet :) > I have similar problem :) I took it just for not being orphaned by some bot. So if you would like to work on it, feel free to take it. Currently, for me the ETA is few weeks.
Well good news and bad news... Adding the environment variable for the CMake policy fixes the build, kind of... As usual with major GCC updates the compilers get more pedantic and now there's an error when linking some of the fortran code: /usr/bin/ld: error: decoder.f90.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) /usr/bin/ld: failed to set dynamic section sizes: No such file or directory collect2: error: ld returned 1 exit status Some googling lead me to adding "-z noexecstack" to LDFLAGS but I'm not sure that's a good idea to add it as a global flag or not but it allows the build to finish.
Oh Fortran the bane of my existence. This is unfortunately something that upstream must design around, iirc it's passing functions that were defined as sub-functions (with local variables inherited) that causes that breakage. I did fix it once, so maybe I can pull it out for reference. But this requires the work to be done upstream, so probably not worth it. What you could do is inject those flags specifically to the Fortran library only so that C/C++ code is unaffected. PS: this was gfortran 14 or 1-2 versions before it when it was introduced.
I'll see about a patch... It's a royal PITA because upstream packages wsjtx and hamlib together in the main archive and treats both as subprojects. Then you have to create the patch as a source file with the correct name it and will be automatically applied by CMake.
After spending way too much time trying to apply a more localized solution I may give up and go with the LDFLAGS solution. Applying 'no-automatic' to all fortran sources broke other objects and trying to modify how just decoder.f90 was built also failed.
I built a local package for f42 using the big hammer (LDFLAGS) but as soon as it tried to decode I got this: Subprocess Error: Running: /usr/bin/jt9 -s WSJT-X -w 1 -m 3 -e /usr/bin -a /home/richard/.local/share/WSJT-X -t /tmp/WSJT-X Process crashed
Workaround implemented for CMake and reported upstream. Gfortran FTBFS issue will be tracked on the new BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2385733