Bug 2351130

Summary: /usr/lib/rpm/macros.d/macros.cmake contained -DLIB_SUFFIX definiton, now it doesn't
Product: [Fedora] Fedora Reporter: Jaroslav Škarvada <jskarvad>
Component: cmakeAssignee: Björn Esser (besser82) <besser82>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: besser82, fedora, laurent.rineau__fedora, orion, rdieter, spotrh, suraj.ghimire7, tfujiwar, trpost, vitaly, walter.pete
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jaroslav Škarvada 2025-03-10 17:03:30 UTC
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

Comment 1 Tom "spot" Callaway 2025-03-10 18:12:36 UTC
This broke scalapack as well, I would imagine other things will break.

Comment 2 Cristian Le 2025-03-11 08:46:18 UTC
`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

Comment 3 Vitaly 2025-03-12 11:10:56 UTC
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}'`.

Comment 4 Vitaly 2025-03-12 11:31:44 UTC
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

Comment 5 Orion Poplawski 2025-03-13 03:39:59 UTC
This also broke libgeotiff.  Please suggest a fix.

Comment 6 Orion Poplawski 2025-03-13 03:43:10 UTC
And rmol, and yes likely many others.

Comment 7 Vitaly 2025-03-13 08:05:21 UTC
> 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

Comment 8 Cristian Le 2025-03-13 10:44:36 UTC
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.

Comment 9 Jaroslav Škarvada 2025-03-14 20:32:17 UTC
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

Comment 10 Jaroslav Škarvada 2025-03-14 20:35:25 UTC
(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.

Comment 11 Jaroslav Škarvada 2025-03-17 14:20:59 UTC
More broken packages:
sdrangel
soapy-uhd

Comment 12 Jaroslav Škarvada 2025-03-19 17:57:45 UTC
(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