master 24096284: binaries are linked with RPATHs

[kloczek]

I cannot find actual option to remove linking with RPATH and during packaging I have error message that binaries are linked with standard libraries path in RPATH.
This shouuld not be default behavior.

*******************************************************************************
*
* 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/bin/qhull' contains a standard  '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/rbox' contains a standard  '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/qconvex' contains a standard  '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/qdelaunay' contains a standard  '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/qvoronoi' contains a standard  '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/qhalf' contains a standard  '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/lib64/libqhull_r.so.8.1-alpha1' contains a standard  '/usr/lib64' in [/usr/lib64]

[cbbarber]

Can someone suggest how to deal with this RPATH problem? The description of '0001' says it is a minor issue, but leads to redundant search paths.

kloczek asked to remove RPATH as the default. mathstuf asked to add it (#94)

Could this be an RPATH configuration problem in kloczek's build environment? 'usr/lib64' is not mentioned in Qhull src files, CMakeLists.txt, or Makefile.

[QuLogic]

I don't think @mathstuf asked to add anything in #94. Rather, he's moved the hard-coded settings to an earlier spot and only set them if not already set. In other words, those are now defaults that could be overridden, whereas before they were always used.

[kloczek]

BTW .. if someone needs to build binaries with hardcoded RPATHs cmake supports that OOTB on demand. https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
This is why hardcoding such features is kind WrongDoing™️ 😋

[kloczek]

BTW .. as my PR hes been merged 😋 is it any plan to release new version? 🤔

BTW2: if may I suggest switch from current v<version>-alpha{1,2,3} convention to v<version>.alpha{1,2,3} so instead
v8.1-alpha{1,2,3} could be v8.1.alpha{1,2,3} and as final version 8.1.0
More details about that versioning/tagging convention is possible to find on https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
Such convention is packaging friendly because many package managers do not accept - in version strings.

[mathstuf]

Such convention is packaging friendly because many package managers do not accept - in version strings.

These packages should have a build field or something to put it. For example, Fedora could tag it as 8.1.0-0.N.alpha1 where N is what Fedora increments for things like patches or rebuilds. The 0. prefix on the release number means "prerelease".

While getting things to be more consistent is good, the sheer number of packages versioned like that mean that packaging systems just need to deal with it.

[mathstuf]

In other words, those are now defaults that could be overridden, whereas before they were always used.

Yes. Our packaging setup is a bit odd in that we prefer projects build with absolute rpaths and library ids (they are all rewritten during the actual packaging step) in order to reduce the amount of faffing around on macOS for @rpath/ usage. Not every project's build system provides an easy way to provide a set of rpaths that may be different for the build and installation.