Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote:
> > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> >> If someone wants to upstream the multi-arch patches, that would be
> >> great.
> >
> > I think multiarch is mostly build-time configuration rather than patches.
>
> We would have to take the table out of dpkg-architecture and put it into
> upstream glibc (or gcc or binutils), otherwise you can't build a
> multi-arch glibc on a non-Debian system.
Sorry, you asked about patches, so I thought you were under the
impression that Debian was patching glibc to have it use multiarch
library directories. I believe it's mainly done with build-time
configuration rather than by patching, so there isn't necessarily
anything to upstream, because most of what's necessary to enable/allow
that build-time configuration is already upstream - unless you want
glibc to be generically aware of multiarch paths even when built on
non-Debian? Is that your goal here?
As I said, a 99% implementation of multiarch tuples is to take the GNU
tuple that any Autotools-based build system already relies on, discard the
vendor part, and normalize a finite number of special cases (i[3456]86
and arm* are the only ones I'm aware of). I believe the people who did
the early design of multiarch were hoping to standardize it via something
like LSB, but that effort seems approximately as dead as LSB itself.
systemd has an independent implementation of the list of known multiarch
tuples:
https://github.com/systemd/systemd/blob/main/src/basic/architecture.h
https://github.com/systemd/systemd/blob/main/src/basic/architecture.c
Some sort of change to the expansion of $LIB is maybe the only thing
needed in addition to build-time configuration, because the upstream
implementation of $LIB makes the assumption that only the last path
segment of the ${libdir} is desired in $LIB, which is usually the case
but happens to be untrue for multiarch.
> In addition to get the right value for $LIB, it's also desirable to get
> the default search paths right.
This is done by runtime configuration rather than patching, at the moment,
for example this file installed as part of libc6:amd64:
$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
If you would prefer this to be hard-coded into ldconfig, I suspect there's
no implementation right now that could be upstreamed.
> And there's also /usr/libexec/getconf to worry about.
At the moment, /usr/bin/getconf is only installed for the "main"
architecture (more precisely, for whichever architecture of libc-bin is
installed). If there's meant to be one getconf per architecture, then it
wouldn't be able to appear in /usr/bin or /usr/libexec with that name.
As with ld.so, this is not unique to multiarch: multilib would have the
same problem.
Is that /usr/libexec/getconf upstream, or is /usr/libexec/getconf
something else?
smcv
Reply to: