On Mon, 15 May 2023 at 18:54, Simon McVittie <s...@debian.org> wrote: > > On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote: > > People build things on Debian that are not Debian packages. People > > compile binaries on Debian, and expect them to work on any system that > > has sufficiently new libraries. > > *raises hand* > > Hello, I represent an example of those people. With my $work hat on, > I'm involved in maintaining a family of Debian derivatives (the Steam > Runtime) that is used to run Steam games on arbitrary distributions, > including but not limited to Debian. Some of these binaries are built > on a Debian derivative, but run on an arbitrary other distribution, > using a RPATH[1] to find their non-glibc dependencies. > > At the moment those binaries are built in ancient environments (based > on Ubuntu 12.04 and Debian 8), but as newer versions of glibc become > ubiquitous, we'll want to start relying on newer versions of Debian > (which will still be very old versions *at the time*, but I'm sure that > by 2030 or 2040 we'll want to be using versions of Debian that, in 2023, > are not released yet). In this use-case, yes we do need to be using the > interoperable ELF interpreter path. > > We were able to use (Ubuntu and) Debian for this *because* Debian is > a relatively "ordinary" distribution that tends to follow cross-distro > standards. The major counterexample is multiarch library paths, but > multiarch library paths have some compelling technical advantages, and > because there's no ambiguity about which architecture uses which directory, > they're actually better for interop in some ways than /usr/lib (which > is ambiguous, because the Red Hat family of distros expects to find 32-bit > libraries there, but the Arch family expects 64-bit libraries, and it's > not possible to construct a tree where both get what they want). > > I've spent a lot of the last 5 years working on putting Steam games in > containers so that they'll work more reliably on all distros, including > Debian, with less reliance on weird library search paths (although we > still have to use binaries built on an ancient Debian derivative with a > non-trivial RPATH to bootstrap the container environment). Because of > constraints around recent GPUs needing current graphics drivers even > if running on an otherwise ancient library stack, Steam's container > runtime has to construct a hybrid environment where glibc is either the > one from the host or the one from the container runtime environment, > whichever is newer; and while doing that, we have experienced some > broken situations that were caused by distributions diverging from the > interoperable ELF interpreter. One concrete example is that Arch Linux > uses the interoperable ELF interpreter for *almost* all executables, > but uses a different ELF interpreter for executables from the glibc > source package, for whatever reason; we were able to work around this, > but for a while it caused Arch to fail to launch these containers where > Debian/Fedora/etc. could.
This sounds like a very interesting use case, and the first real one mentioned, which is great to see - but I do not fully follow yet, from what you are saying it seems to me that what you need is for your binaries to use the usual pt_interp, that bit is clear. But why does it matter if /usr/bin/ls on the host uses a different one? It's your executables that you ship as part of that runtime that are the entry points that need the usual loader path for your chroot-on-steroids, no? The loader would still be reachable as it always was in this theoretical exercise. I am probably missing something in how this works in details. Kind regards, Luca Boccassi
