* Except for non-glibc distributions of course.
Because Linux userland is an unmitigated clusterfuck of bad design that makes this really really really hard.
GCC/Clang and Glibc make it effectively impossible almost impossible to do this on their own. The only way you can actually do this is:
1. create a userland container from the past 2. use Zig which moved oceans and mountains to make it somewhat tractable
It's awful.
But I agree that this should just be a simple target SDK flag.
I think the issue is that the Linux community is generally hostile towards proprietary software and it’s less of an issue for FLOSS because they can always be compiled against the latest.
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
That never took off though, containers are easier. Wirh distrobox and other tools this is quite easy, too.
It's definitely not easy, but it's possible: using the `.symver` assembly (pseudo-)directive you can specify the version of the symbol you want to link against.
Wrong.
> on a VM.
Wrong.
Cross-compiling is a thing.
Of course, you both leave out that you could do it “on real hardware”.
But none of this matters. The real point is that you have to compile on an old distro. If he left out “in a VM”, you would have had nothing to correct.
Why doesn't the glibc use the version tag to do the appropriate mapping?
In other words, the Linux desktop as a whole is a Bazaar, not Cathedral.
This was true in the 90s, not the 2020s.
There are enough moneyed interests that control the entirety of Linux now. If someone at Canonical or Red Hat thought a glibc version translation layer (think WINE, but for running software targeted for Linux systems made more than the last breaking glibc version) was a good enough idea, it could get implemented pretty rapidly. Instead of win32+wine being the only stable abi on Linux, Linux could have the most stable abi on Linux.
It allows (among other things) the glibc developers to change struct layouts while remaining backwards compatible. E.g. if function f1 takes a struct as argument, and its layout changes between v2 and v3, then glibc_v2_f1 and glibc_v3_f1 have different ABIs.
Or at least the oldest one made before glibc's latest backwards incompatible ABI break.
The only thing that is lacking is an SDK to easily target older glibc versions compared to the one you are using on your build server - but that's something that you can build yourself with some effort.
