Description of problem: The result of `geos-config --clibs` includes the standard search path /usr/lib64. This breaks building any package that requires it, as check-rpaths fails during RPM build. Version-Release number of selected component (if applicable): geos-3.9.2-1.fc35.x86_64 geos-3.10.2-5.fc37.x86_64 geos-devel-3.9.2-1.fc35.x86_64 geos-devel-3.10.2-5.fc37.x86_64 Steps to Reproduce: 1. Install geos-devel 2. Run geos-config --clibs Actual results: -L/usr/lib64 -lgeos_c Expected results: -lgeos_c Additional info: Any shared library that uses this result to link will fail RPM build on the check-rpaths script: ******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH OR RUNPATH and will cause * 'rpmbuild' to fail. To ignore these errors, you can set the * '$QA_RPATHS' environment variable which is a bitmask allowing the * values below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk * 0x0004 ... insecure RPATHs; these are relative RPATHs which are a * SECURITY risk * 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other * RPATHs; this is just a minor issue but usually unwanted * 0x0010 ... the RPATH is empty; there is no reason for such RPATHs * and they cause unneeded work while loading libraries * 0x0020 ... an RPATH references '..' of an absolute path; this will break * the functionality when the path before '..' is a symlink * * * Examples: * - to ignore standard and empty RPATHs, execute 'rpmbuild' like * $ QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild my-package.src.rpm * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like * $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths * ******************************************************************************* ERROR 0001: file '/usr/lib64/python3.10/site-packages/cartopy/trace.cpython-310-x86_64-linux-gnu.so' contains a standard runpath '/usr/lib64' in [/usr/lib64]
Isn't the issue rather that -rpath appears in the `cartopy/trace.cpython-310-x86_64-linux-gnu.so` link command?
Hmm, I think you are right, I don't really know why we do this. I've both patched the `-rpath` out and switched geos-config to pkg-config instead, and the build progressed correctly. I seem to recall it was a bad idea to pass -L/usr/lib64, but perhaps I am conflating that with rpath, as I can't find any docs saying so right now. Feel free to close if you don't see any need to change anything.
Ok, closing - -L/usr/lib64 really shouldn't hurt (as long as it is the correct dir for the compilation target).