Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> Having ld.so as a real command makes the name architecture-agnostic.
> This discourages from hard-coding non-portable paths such as
> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 in scripts that require
> specific functionality offered by such an explicit loader invocation.
This works up to a point, but because there is only one /usr/bin/ld.so,
it can only work for one architecture per machine, so saying it's
architecture-agnostic is still a bit of a stretch.
In multiarch, in principle there is no such thing as "the" primary
architecture (it is valid to combine sed:amd64 and coreutils:i386 on an
amd64 kernel), but in practice it's usually the case that "most"
executables come from the same architecture as dpkg.
So if we only have one ld.so, then on typical Debian x86_64 machines
it will only work for x86_64 executables, and not for i386 executables
(or cross-executables via qemu-aarch64-static or whatever). Similarly,
on Red Hat-style multilib, it will only work for x86_64 and not for
i386. Does that give you the functionality you are expecting?
One way to make it closer to architecture-agnostic would be to name it
${tuple}-ld.so, similar to how gcc (cross-)compilers are named. From
Debian's point of view, ideally the tuple would be a multiarch tuple,
which is a GNU tuple normalized to eliminate differences within an
ABI-compatible family of architectures:
- start from the GNU tuple, e.g. i686-pc-linux-gnu
- discard the vendor part, e.g. i686-linux-gnu
- this version is the tools prefix used in cross-compilation
- replace i?86 with i386 and arm* with arm, e.g. i386-linux-gnu
- this version is the Debian multiarch tuple
(Or perhaps better to have symlinks with both the cross-tools prefix
and the multiarch tuple, where they differ - which I believe is only
i386 and 32-bit ARM, because most/all other architectures sensibly change
the GNU tuple if and only if the ABI is different.)
> The initial implementation will be just a symbolic link. This means
> that multi-arch support will be missing: the amd64 loader will not be
> able to redirect execution to the s390x loader.
... or to the i386 loader, which is probably a concern for more people
(that affects Red Hat-style multilib, which is present in some form on
most distros, and not just Debian-style multiarch, which is only seen in
Debian derivatives and the freedesktop.org SDK).
> In principle, it should
> be possible to find PT_INTERP with a generic ELF parser and redirect to
> that, but that's vaporware at present. I don't know yet if it will be
> possible to implement this without some knowledge of Debian's multi-arch
> support in the loader.
I believe Debian uses the interoperable (ABI-compliant) ELF interpreter
as listed on https://sourceware.org/glibc/wiki/ABIList for all
architectures - it certainly does for all *common* architectures (for
example our x86_64 executables use /lib64/ld-linux-x86-64.so.2, which is
a special exception to the rule that we don't usually use lib64).
I had naively believed that all distros do the same, but unfortunately
my work on the Steam Runtime has taught me otherwise: for example, Arch
Linux has a non-standard ELF interpreter /usr/lib/ld-linux-x86-64.so for
executables that are built from the glibc source package (but uses the
interoperable ELF interpreter for everything else), and Exherbo
consistently puts their dynamic linkers in /usr/x86_64-pc-linux-gnu/lib.
Does glibc automatically set up the interoperable ELF interpreter, or is
it something that distros' glibc maintainers have to "just know" if they
are using a non-default ${libdir}?
> If someone wants to upstream the multi-arch patches, that would be
> great. glibc now accepts submissions under DCO, so copyright assignment
> should no longer be an obstacle.
(Please note that I am not a glibc maintainer and cannot speak for them.)
I think multiarch is mostly build-time configuration rather than patches.
The main thing needing patching is that we want ${LIB} to expand to
lib/x86_64-linux-gnu instead of just x86_64-linux-gnu, so that the
"/usr/${LIB}/libfoo.so.0" idiom works, but glibc would normally only take
the last component of the ${libdir}:
https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/any/local-ld-multiarch.diff
The freedesktop.org SDK used for Flatpak also uses Debian-style multiarch
(but is not otherwise Debian-derived), and addresses that differently, in a
way that might be more upstream-suitable:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/patches/glibc/fix-dl-dst-lib.patch
smcv
Reply to: