What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.
glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.
I guess you didn’t mention glibc in your comment but I already typed this out
From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.
Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.
(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)
> Stable ABI literally only benefits software where the user doesn’t have the source.
It also benefits people who don't want to have to do busywork every time the OS updates.
Stable ABI benefits everyone. If I need to recompile a hundred packages with every OS update instead of doing real work then there's something seriously wrong with my OS.
Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.
The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.
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.
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.
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
for example here is a 20 year old binary of the game mirrormagic that runs just fine on my modern fedora machine:
~/Downloads/mirrormagic-2.0.2> ldd mirrormagic
linux-gate.so.1 (0xf7f38000)
libX11.so.6 => /lib/libX11.so.6 (0xf7db5000)
libm.so.6 => /lib/libm.so.6 (0xf7cd0000)
libc.so.6 => /lib/libc.so.6 (0xf7ad5000)
libxcb.so.1 => /lib/libxcb.so.1 (0xf7aa9000)
/lib/ld-linux.so.2 (0xf7f3b000)
libXau.so.6 => /lib/libXau.so.6 (0xf7aa4000)
~/Downloads/mirrormagic-2.0.2> ls -la mirrormagic
-rwxr-xr-x. 1 em-bee em-bee 203633 Jun 7 2003 mirrormagic