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.
> > 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.
> > Packages compiled for Debian Trixie are going to be built against
> > Trixie's glibc, they can't really be expected to _always_ work against
> > _any_ other libc, no?
>
> For Fedora & downstream, we make sure that glibc (and the GCC shared
> objects) have exactly the same ABI as upstream for each symbol
> versioning set. I believe Debian does the same. For glibc, we have
> some additional backports with bug fixes and the occasional performance
> enhancement, relevative to the corresponding upstream stable release
> branch for glibc. For GCC, I believe there are even fewer differences.
>
> So for Fedora & downstream, the binaries will be interoperable with
> upstream versions. I think the same is true for Debian relative to
> upstream, so Debian/Fedora binaries should interoperate as well.
>
> Statically-linked binaries that call dlopen (indirectly, say via NSS or
> iconv) tend to be not portable across distributions, but that's a rather
> narrow use case.
Right, but new symbols do get added and used, so a Debian package
built for Trixie is not guaranteed to work on Buster, and so on.
> >> > 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]
Kind regards,
Luca Boccassi
