Currently, our binutils is "switched" to emitting RUNPATH over RPATH by default, using a patch. This is generally a good thing, because RUNPATH has weaker precedence than RPATH and users can override the lookup using LD_LIBRARY_PATH (which RPATH does not allow). Unfortunately, we're doing it in a rather unorthodox way: using a patch that changes the linker defaults. This is regrettable, because the patch isn't perfect and there's a configure option to change the default (--enable-new-dtags). At least Debian (https://sources.debian.org/src/binutils/2.37-1/debian/rules/#L404) and Fedora (https://src.fedoraproject.org/rpms/binutils/blob/rawhide/f/binutils.spec#_75) both enable new dtags through configure and we should too.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/toolchain/binutils-patches.git/commit/?id=8699e74a960289b51ace04e4fffde22d5344171b commit 8699e74a960289b51ace04e4fffde22d5344171b Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-08-17 20:01:35 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-08-17 20:01:35 +0000 Enable new dtags via configure, not broken patch Bug: https://bugs.gentoo.org/808787 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> ...nable-new-dtags-by-default-for-linux-gnu-.patch | 49 ---------------------- 1 file changed, 49 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b87a28ed9cc331f51b67eb723f6931b34c7e9d25 commit b87a28ed9cc331f51b67eb723f6931b34c7e9d25 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-08-17 20:01:09 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-08-17 20:07:45 +0000 sys-devel/binutils: Enable new dtags via configure, not broken patch Bug: https://bugs.gentoo.org/808787 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-devel/binutils/binutils-9999.ebuild | 2 ++ 1 file changed, 2 insertions(+)
This bug mainly came about by looking into another failure (https://bugs.gentoo.org/803944). espeak-ng would build and install fine on amd64, but would fail reproducibly on arm/arm64. The failure was odd, because the necessary library (libespeak-ng.so.1) was present and in the right directory, it just wasn't being loaded, which excludes the possibility of a race condition. It turns out, on arm64, the libtool wrapper for the actual binary was lacking the LD_LIBRARY_PATH injection that the same wrapper script on amd64 had present. The question now turned to why amd64 had LD_LIBRARY_PATH injection and arm64 didn't? Something was tripping up libtool and it wasn't obvious. Diffing config.log (noise omitted): -uname -m = x86_64 +uname -m = aarch64 -lt_cv_shlibpath_overrides_runpath=yes +lt_cv_shlibpath_overrides_runpath=no So on arm64, libtool decided that if the binary had a "RUNPATH", any libraries found via that path couldn't be overridden. Tracing back to why libtool's checks actually decided this: we arrive at the following line in libtool: https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n2880 i.e., libtool checks exactly what type of entry "-Wl,-rpath" creates in the binary. If the values is "RUNPATH", then lt_cv_shlibpath_overrides_runpath gets set to "yes". A quick link check confirmed that on amd64 RUNPATH was being used, but on arm/arm64 RPATH was being used. The question now turned to why the arm was being different here. We are carrying a patch in our patch archive https://gitweb.gentoo.org/proj/toolchain/binutils-patches.git/commit/9999 which (supposedly) changes the dtag to "new" (i.e. RUNPATH). Debugging this further, the following conditional does NOT trigger for arm/arm64: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/emultempl/elf.em;h=bfaf8130a3e62802057a83b9dabf791283ddbecb;hb=HEAD#l68 In the case of arm, the functions did NOT get overridden, which meant that vapier's patch was never active on arm/arm64, leading to an ld that preferred creating RPATH over RUNPATH.
(In reply to David Seifert from comment #3) > [...] > The question now turned to why the arm was being different here. We are > carrying a patch in our patch archive > > https://gitweb.gentoo.org/proj/toolchain/binutils-patches.git/commit/9999 > Now-removed patch: https://gitweb.gentoo.org/proj/toolchain/binutils-patches.git/tree/9999/0005-Gentoo-ld-enable-new-dtags-by-default-for-linux-gnu-.patch?id=7d4ad0cdad6d8eda51cc091f9357fe9d13c3f1e2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6b9cdfbb7ca36a1295db5e18ce5a05d76499645a commit 6b9cdfbb7ca36a1295db5e18ce5a05d76499645a Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-08-17 21:29:17 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-08-17 21:42:40 +0000 sys-devel/binutils: 2.37 patchset bump Needs pseudo-version since sources of generated files were changed Bug: https://bugs.gentoo.org/808787 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-devel/binutils/Manifest | 2 + sys-devel/binutils/binutils-2.37_p1.ebuild | 454 +++++++++++++++++++++++++++++ sys-devel/binutils/binutils-9999.ebuild | 7 +- 3 files changed, 461 insertions(+), 2 deletions(-)
