Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#76274 - [binutils] consider building with --enable-new-dtags

Attached to Project: Arch Linux
Opened by Max (mmustermann) - Sunday, 23 October 2022, 11:19 GMT
Last edited by freswa (frederik) - Monday, 05 December 2022, 21:06 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Levente Polyak (anthraxx)
freswa (frederik)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


Currently Arch doesn't build its binutils with the "--enable-new-dtags" configure option but Debian, Ubuntu, Gentoo, Fedora, NixOS and probably more do so. This caused some hard to track down build inconsistencies for me, i.e. scripts generated by libtool do not work on Arch when their path contains a comma (more on that below in the steps to reproduce). It would be great if Arch could also enable the new dtags for the binutils so that projects build the same on the major distros.
The only other relevant information I could find about this topic was a forum post, where user "snack" seems to have a similar problem: So if building with "--enable-new-dtags" was discussed before or this is not the appropriate place, please let me know.

What does this do?:
The --enable-new-dtags configure option causes the linker to set the --enable-new-dtags option as default. This means that "-Wl,-rpath" will produce the DT_RUNPATH symbol instead of DT_RPATH:

Additional info:
Debian and Ubuntu use --enable-new-dtags since binutils and
Gentoo used a custom patch to enable the new dtags (at least) since 2012 but switched to --enable-new-dtags last year: and
Fedora enabled the new dtags last year with binutils 2.36.1-10:
NixOS also enabled the new dtags back in 2008 and switched to --enable-new-dtags in 2018: and and

Steps to reproduce / How I encountered this:
I have to use a framework at work which uses benchbuild ( under the hood to automatically compile projects and run some experiments. This framework/benchbuild clones a project and checks it out in a folder containing a comma. E.g. xz gets checked out at "xz-c_projects@2611c4d905,1.0". You can compile xz in such a folder just fine and libtool generates a script at "src/xz/xz". The purpose of the script is to wrap the generated binary and always execute it with the right liblzma version so that developers don't have to install xz system wide if they want to test a change. However, executing the script fails because the "relink_command" in the script fails with "/usr/bin/ld: cannot find 1.0/xz-2611c4d905/src/liblzma/.libs". Note the missing part of the path in front of the comma. This is caused by the linker flags "-Wl,-rpath -Wl,/tmp/xz-c_projects@2611c4d905,1.0/src/liblzma/.libs" in the "relink_command". Libtool doesn't escape the comma in the path and manually escaping the comma doesn't seem to work either. GCC/Clang don't seem to support escaping in linker flags. If you know how to escape the comma properly, please let me know!
So far so good, but why does this script work on Debian, etc.? Turns out that the "relink_command" is actually empty there. The relevant flag for libtool that causes the change in the generated script is "shlibpath_overrides_runpath" which gets set to "no" in Arch and "yes" in Debian and co. The reason for this is that this line ( is not executed because our ld does not set DT_RUNPATH by default.

I've attached a script which reproduces the issue.
This task depends upon

Closed by  freswa (frederik)
Monday, 05 December 2022, 21:06 GMT
Reason for closing:  Implemented
Additional comments about closing:  binutils-2.39-4
Comment by freswa (frederik) - Sunday, 23 October 2022, 13:38 GMT
Thank you for the detailed report. Looking into it.