* 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. > 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