* Luca Boccassi: > On Mon, 15 May 2023 at 10:57, Florian Weimer <fwei...@redhat.com> wrote: >> >> * Luca Boccassi: >> >> > On Mon, 8 May 2023 at 23:08, Florian Weimer <fwei...@redhat.com> wrote: >> >> >> >> * Luca Boccassi: >> >> >> >> > But the more I think about it, the more I am convinced that the >> >> > default option working best for Debian is the one that matches the >> >> > project's choice of a filesystem layout. After all, this is >> >> > configurable in the toolchain for a reason. >> >> >> >> It's not really configurable. You need to use what's specified in the >> >> psABI supplement, otherwise the binaries won't be interoperable with >> >> other systems, effectively creating a Debian-specific ABI. >> > >> > The vast majority of distros today ship the loader in /usr/lib as /lib >> > is just a symlink, so it would be interoperable. >> >> I don't think that's true. Debian-style multi-arch paths have not been >> contributed upstream to the GNU toolchain. > > I was not referring to the Debian-specific multiarch, but to the > generic usr-merge. As far as I am aware, in the vast majority of > distros that ship today /lib/ is a symlink to /usr/lib/, etc. Ubuntu, > Suse, Arch, Fedora, RHEL, CentOS, Mandriva, Gentoo, Amazon, Mariner, > and so on.
But ld.so is often not in /lib because the Linux ABI mandates a path under /lib64. >> > And anyway, the rest of the system is not really interoperable, is it? >> >> If you pick an old enough distribution and stick to a subset of shared >> objects with ABI stability, binaries are generally portable. It's not >> what we recommend, but it's how most proprietary software comes to >> Debian and other distributions. > > Sure, but proprietary/third party software wouldn't be affected. Except if it is built on Debian. >> >> > On the 'how' question there's obviously some options - patching >> >> > GLIBC_DYNAMIC_LINKER* defines, adding optional build time prefixes to >> >> > them, or a ship a default spec file - so it's not too important I >> >> > think, the main question is another one. >> >> >> >> There's no single place to patch this across the various toolchains and >> >> architectures. >> > >> > In terms of 'how', wouldn't a spec file pulled in by default by our >> > toolchain that sets -Wl,-dynamic-linker=... as needed suffice? AFAIK >> > there are other distros doing this distro-wide, so there must be a >> > workable way. >> >> Other distributions are probably smaller. Not everything uses gcc as >> the compiler driver to link all programs. For example, you'll have to >> patch the Clang compiler driver separately. I think both Go and FPC >> have their own linkers or linker invocations, too. > > Are you sure patching anything would be actually needed? llvm seems to > support -Wl,-dynamic-linker just fine, even on stable: > > $ clang -Wl,-dynamic-linker=/usr/lib64/ld-linux-x86-64.so.2 test.c > $ readelf -a a.out | grep interpreter > [Requesting program interpreter: /usr/lib64/ld-linux-x86-64.so.2] I thought you wanted to patch this as a default into the compiler drivers. Even with the -Wl,… approach, I think it's a rather pointless ABI divergence. Thanks, Florian
