On Fri, 09 Jun 2023 at 11:04:47 +0800, Paul Wise wrote: > On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > > modern x86_64 systems > > Are these use-cases likely to work with future library ABIs, or > do they need old library ABIs from when the binaries were compiled?
I'm not sure how this could be in question? They're legacy binaries, so almost by definition, legacy ABIs. > > 2a. legacy native Linux i386 binaries > > It seems like modern Debian library ABIs will be bumped away from what > the old i386 binaries were built against, so future Debian i386 won't > be useful for this use-case anyway, except for very stable libraries, > symbol versioned libraries or libraries with multiple ABIs. That sounds > like glibc, X11 and SDL with compat libs. Anything else? When you say "ABIs will be bumped", do you mean SONAME transitions like libtiff.so.4 -> .5 -> .6? Those don't have to prevent running legacy binaries if we don't want them to, because the whole point of SONAMEs is that different versions of the same library are co-installable: if you have a legacy binary linked to libtiff4, you can still run it on a system that normally uses libtiff6 by keeping a copy of libtiff4 from an old Debian suite (I know it's in Ubuntu 12.04, but I've lost track of how old you would need to go in Debian-world to get it). This will generally work fine as long as the legacy binary doesn't also link to a higher-level library that depends on a modern version of libtiff, like for example libsdl-image1.2 or libsdl2-image-2.0-0. Even if the legacy binary *does* link to such a library, then it might still work, if both the old and new versions of libtiff have ELF symbol versioning (libtiff6 does, I think libtiff4 also did) and the higher-level library doesn't expose libtiff objects through its own ABI (SDL_image doesn't). If the legacy binary mostly calls into higher-level "middleware" libraries like SDL_image, then it is quite likely that it doesn't actually directly reference any symbols from a lower-level library like libtiff, and the lower-level libraries tend to be the ones that break ABI most often. >From my experience in dealing with the Steam Runtime, I can tell you that surprisingly many of the libraries linked by legacy binaries still have an ABI that is backwards-compatible with versions of the same library from more than 10 years ago. For example, PulseAudio never bumped SONAME; GLib, libdrm and fontconfig had some SONAME bumps in their early history but are long-term-backwards-compatible now; and libjpeg bumped SONAME somewhat recently, but Debian is using the maximally-backwards-compatible ABI. I can't tell you a comprehensive list of libraries used by legacy binaries, but if someone wants to audit all the "commonly used" libraries for whether 64-bit time_t breaks their ABIs, the Steam Runtime is probably quite a good approximation of what is "commonly used": https://repo.steampowered.com/steamrt-images-sniper/snapshots/latest-container-runtime-public-beta/com.valvesoftware.SteamRuntime.Platform-amd64%2Ci386-sniper.source-required.txt I must admit that I stopped looking when I saw that libX11 and libasound have time_t in their ABI, because those are both going to be extremely common dependencies, and I am not optimistic about the prospects of getting glibc-style parallel ABIs into libX11. smcv
