[serbuvlad]

This is not an ABI stability problem, this is a UX problem.

iOS and Android do backwards incompatibility all the time. If you find a mobile app that hasn't been updated in 10 or 15 years, you won't be able to install it on a modern device. But, iOS and Android ship apps to billions of users, nobody complains about ABI stability and nobody uses a Win32 compatibility layer.

glibc already has decent UX in that it doesn't allow you to load an app built for a newer version on a host with an older version. Unfortunately, the message is not user friendly at all "could not load @@GLIBC_X.YZ@@foo()", instead of something more readable, but the restriction is, in itself, good.

The problem is that there is no system to trigger backwards incompatibility at any point, nor is there a simple way to target an older Glibc version without spinning up a docker container.

And glibc is a HELL of a codebase, I would NOT want to be responsible for implementing those features, so I understand why they're not there. But 'our Linux build for our game we are still selling and advertising as working on Linux is no longer compatible with new Linux distributions, so let's rebuild it' is a much easier decision for a developer, publisher, etc. to make than '"some" Linux users are reporting issues with our game, should we dedicate resources to investigating this?'

[saurik]

> nor is there a simple way to target an older Glibc version without spinning up a docker container

? I feel like you might be falling into the trap of assuming that the compiler always targets the current running system, but you 100% should always always always be doing a Linux-to-Linux "cross" compile with a sysroot... you don't need a docker container: you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it.

[serbuvlad]

> you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it

That sounds like more work than spinning up a Docker container though. I'm imagining

    gcc --glibc-target=2.31

[saurik]

Spinning up a Docker container the way I'm kind of assuming you are talking about is going to involve running the compiler in there, which is super annoying -- and extremely limited, as you often are going to get stuck with old versions of all of your toolchain components as well -- and certainly way more difficult than just extracting the distribution to disk and using gcc --sysroot=/path/to/glibc-2.31.

[edflsafoiewq]

How?

[throwaway2046]

> glibc [...] doesn't allow you to load an app built for a newer version on a host with an older version

> the restriction is, in itself, good.

Why do you consider this a good restriction?

[serbuvlad]

Because if function foo's third flag parameter supports FOO_ENABLE_FEATURE_X starting from 2.31, and a program only occasionally calls foo with this flag, there is no good way to detect this incompatibility on a 2.30 system at link time.

The restriction is only annoying because there is no way to trivially link against an older "minimum requirement" ABI.