E.g. f41: $ grep -C2 lib_suffix64 /usr/lib/rpm/macros.d/macros.cmake # Macros for cmake # %_cmake_lib_suffix64 -DLIB_SUFFIX=64 %_cmake_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON [yarda@yarda macros.d]$ grep -C2 lib_suffix64 /usr/lib/rpm/macros.d/macros.cmake # Macros for cmake # %_cmake_lib_suffix64 -DLIB_SUFFIX=64 %_cmake_shared_libs -DBUILD_SHARED_LIBS:BOOL=ON %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON -- -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \\\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\\ %endif \ %{?_cmake_shared_libs} f43: $ grep -C2 lib_suffix64 /usr/lib/rpm/macros.d/macros.cmake <EMPTY> It broke gnuradio build on ppc64 and s390x. Although, it hide gnuradio bug and I will report it to gnuradio upstream to fix their lib64 auto-detection, I wonder why it was dropped. Reproducible: Always Steps to Reproduce: 1. $ grep -C2 lib_suffix64 /usr/lib/rpm/macros.d/macros.cmake 2. 3. Actual Results: EMPTY Expected Results: -DLIB_SUFFIX definition cmake-4.0.0~rc3-3.fc43.x86_64
This broke scalapack as well, I would imagine other things will break.
`LIB_SUFFIX` along with the other ones were never a standard implementation and it is unclear what their usage is meant and instead the package themselves should evaluate if and how they need it [1,2]. Since then `GNUInstallDirs` has become the defacto approach that accounts for all of it. I did an preliminary search for their usage [3] and found it relatively low, so, if you are affected, contact me and I will personally write a patch for it and submit it to upstream. - `gnuradio` looks like it should work without any such definitions from what I saw in their implementation since they are just manually replicating GNUInstallDirs for some reason [4] - `scalapack` is a more interesting case since it installs in the mpi directories having a different standard. Normally you would use ``` -DCMAKE_INSTALL_PREFIX:PATH=${MPI_HOME} -DCMAKE_INSTALL_LIBDIR:PATH=lib ``` But it requires some patching upstream, I will help make a patch for it. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1425064 [2]: https://gitlab.kitware.com/cmake/cmake/-/issues/18640 [3]: https://sourcegraph.com/search?q=context%3Aglobal+set%5C%28INCLUDE_INSTALL_DIR.*CACHE&patternType=regexp&case=yes&sm=0 [4]: https://github.com/gnuradio/gnuradio/blob/4722ef5b2894be5bc69ddf669232be6eba1b0cca/cmake/Modules/GrPlatform.cmake#L45-L56
It broke psi, psi-plus and jdns packages. Please return it back. As a workaround, I set absolute path with `-DPSI_LIBDIR:PATH='%{_libdir}/%{name}'`.
Psi-plus uses it everywhere in their CMake. Better workaround: %if 0%{?fedora} && 0%{?fedora} >= 43 %if "%{?_lib}" == "lib64" -DLIB_SUFFIX:STRING=64 \ %endif %endif
This also broke libgeotiff. Please suggest a fix.
And rmol, and yes likely many others.
> Please suggest a fix. Workaround: %if 0%{?fedora} && 0%{?fedora} >= 43 %if "%{?_lib}" == "lib64" -DLIB_SUFFIX:STRING=64 \ %endif -DLIB_INSTALL_DIR:PATH="%{_libdir}" \ %endif
I've made a PR upstream and downstream for rmol and libgeotiff. But as vitaly mentioned, an acceptable workaround is to re-introduce those variable in the spec file, even without the `%if 0%{?fedora}`. But do please report the affected packages because upstream should really be migrating to those, not only for us, but for all distribution environments. Many times the patch is fairly simple as with gnuradio, but I usually go one step further and fix the config.cmake file as well.
It seems uhd is also affected, upstream ticket (it originally started as gcc-15, but this problem is also mentioned there): https://github.com/EttusResearch/uhd/issues/844
(In reply to Jaroslav Škarvada from comment #9) > It seems uhd is also affected, upstream ticket (it originally started as > gcc-15, but this problem is also mentioned there): > https://github.com/EttusResearch/uhd/issues/844 I think the target they install the udev rules now is incorrect, thus it may be easy fix.
More broken packages: sdrangel soapy-uhd
(In reply to Jaroslav Škarvada from comment #11) > More broken packages: > sdrangel https://github.com/f4exb/sdrangel/issues/2419 > soapy-uhd https://github.com/pothosware/SoapyUHD/issues/62