Re: using spec file or patchelf for Debian packages to canonicalize ld path [was: Switching GLIBC_DYNAMIC_LINKER in Trixie]

[Florian Weimer <fweimer@redhat.com>]

* Luca Boccassi:

> On Mon, 15 May 2023 at 10:57, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * 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.
>
> 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