Re: Switching GLIBC_DYNAMIC_LINKER in Trixie
* Luca Boccassi:
> On Mon, 8 May 2023 at 23:08, Florian Weimer <fweimer@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.
> 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.
> 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.
>> > 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.
Thanks,
Florian
Reply to: