Comment by kelnos
23 days ago
> What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
I don't know what the official policy is, but glibc uses versioned symbols and certainly provides enough ABI backward-compatibility that the Python package ecosystem is able to define a "manylinux" target for prebuilt binaries (against an older version of glibc, natch) that continues to work even as glibc is updated.
Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up
If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work
>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.
Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.
The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.
Naturally the downside is that each app bundles their own libraries.
The only problem with this approach is that glibc cannot have multiple versions running at once
that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.
this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:
https://stackoverflow.com/questions/2856438/how-can-i-link-t...
the problem for companies developing on linux is that it is not trivial
glibc must match the linker so you would need a separate linker and the binaries usually have a hardcoded path to the system linker (and you need to binary patch the stuff - https://stackoverflow.com/questions/847179/multiple-glibc-li...)
So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)
You compile in a container/chroot with the userspace you target. Done.
In the context of games, that will likely be Steam Runtime.
2 replies →
MUSL is a better libc for companies making proprietary binaries. They can either statically link it, or provide a .so with the musl version they want their programs to use & dynamically link that.