Bug 2088864

Summary:	geos-config --clibs incorrectly includes standard library path
Product:	[Fedora] Fedora	Reporter:	Elliott Sales de Andrade <quantum.analyst>
Component:	geos	Assignee:	Sandro Mani <manisandro>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	35	CC:	devrim, jmlich83, manisandro, tom
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-23 22:50:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Elliott Sales de Andrade 2022-05-21 05:27:38 UTC

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]

Comment 1 Sandro Mani 2022-05-21 20:07:21 UTC

Isn't the issue rather that -rpath appears in the `cartopy/trace.cpython-310-x86_64-linux-gnu.so` link command?

Comment 2 Elliott Sales de Andrade 2022-05-23 22:41:30 UTC

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.

Comment 3 Sandro Mani 2022-05-23 22:50:47 UTC

Ok, closing - -L/usr/lib64 really shouldn't hurt (as long as it is the correct dir for the compilation target).