Arch Linux

Description:
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: https://bbs.archlinux.org/viewtopic.php?id=264419. 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: https://wiki.archlinux.org/title/Arch_package_guidelines/Security#RPATH/RUNPATH

Additional info:
Debian and Ubuntu use --enable-new-dtags since binutils 2.28.51.20170620-1: https://changelogs.ubuntu.com/changelogs/pool/main/b/binutils/binutils_2.39-3ubuntu1/changelog and https://changelogs.ubuntu.com/changelogs/pool/main/b/binutils/binutils_2.39-3ubuntu1/changelog
Gentoo used a custom patch to enable the new dtags (at least) since 2012 but switched to --enable-new-dtags last year: https://bugs.gentoo.org/808787 and https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/binutils/binutils-9999.ebuild?id=ce0517c95a160042a342a1eaef5b02e9e442ca7f#n264
Fedora enabled the new dtags last year with binutils 2.36.1-10: https://koji.fedoraproject.org/koji/buildinfo?buildID=2070126
NixOS also enabled the new dtags back in 2008 and switched to --enable-new-dtags in 2018: https://github.com/NixOS/nixpkgs/blob/31acb601e388eb7d552f137dbe5cb4677fdf1c3c/pkgs/development/tools/misc/binutils/default.nix#L167 and https://github.com/NixOS/nixpkgs/commit/25245042c2671054a8229aaa90f9050777174c00 and https://github.com/NixOS/nixpkgs/commit/18f517fbd626ee0d4502f2237bbcc837366b4c74

Steps to reproduce / How I encountered this:
I have to use a framework at work which uses benchbuild (https://github.com/PolyJIT/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 (https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4?id=6132006b5fb6b95f31c30a972fbb829f93e1878b#n2878) is not executed because our ld does not set DT_RUNPATH by default.

I've attached a script which reproduces the issue.