Ancient glibc versions run ok on current kernels, you're just missing out on some newer features. Otherwise statically linked binaries would cease to work.
It is not that trivial, and there have been breaking kernel changes that prevent running ancient glibc versions. Fortunately, glibc is open source, so you can actually patch it to run in older versions.
Just grep a kernel's Kconfig and see how many entries claim "this will break binary compatibility".
Even compilers are not that good at building old software.
I remember some funny problems with Glibc, like, 20 years ago, but it's been invisible to me (as a user) since then. You get a new Glibc, old binaries still work, it's fine.
Compatibility works the other way around. You can run binaries compiled against an older libc on a newer glibc, but there's no reason to expect that binaries compiled against a newer libc should be able to run against older versions of libc. If you demand that, you demand software stasis.
If a binary from 2000 doesn't run, it's because of glibc ABI changes. I still have faint memories of glibc crap happening in the early 2000s. But if the binary from 2000 is statically linked, then the Linux kernel probably runs it fine today.
Which is weird considering the argument you had with others above about how "Linux (kernel) doesn't run software", was it a buildup to convince us that "GNU(glibc)/Linux" is really bad at running old binaries? Because your argument doesn't hold for the Linux kernel itself running statically linked binaries.
Isn't glibc, specifically, very careful about ABI compatibility?
You can still run Linux programs linked against decades-old versions of glibc on current systems as they have kept ABI compatibility with the use of symbol versioning, without changing their SONAME ("libc.so.6").
Sure, that does not extend to being able running programs linked against new glibc symbols on old systems, but if you consider that ABI-breaking then the Linux kernel would also be ABI-breaking as you cannot run binaries relying on new kernel syscalls (etc) on older Linux kernels.
An issue here is that statically linking against glibc is generally regarded as a poor idea and I’ve seen a couple non trivial programs that refuse to run with other libc’s.
Yes, you can compile with a really old glibc and use it on a newer one.
But glibc does introduce incompatible changes that make it not work the other way and there are issues with stable ABI's across distros.
This is the opposite problem of what's being talked about. Binaries built against old versions of glibc should run just fine against newer versions. This is about a binary built against a newer version of glibc that doesn't run on an older one. This is common, and super annoying. There are ways to build to eliminate this problem, but they all feel like hacks, or involve a lot of extra work.
(Hacks such as https://github.com/wheybags/glibc_version_header -- which apparently does work very well, but still feels like an annoying hoop that should be unnecessary to jump through. I wish glibc's shipped headers actually could support this out of the box so you could set a preprocessor define like `-DGLIBC_TARGET_ABI=2.12` and it would just work.)
Not really. The kernel obviously is compatible with older versions of libc, but glibc is also compatible with older kernel versions (down to 3.2 for the latest version), and it even attempts to emulate some system calls if your kernel doesn't support them. You've quite some freedom to mix versions.
For glibc/linux target, don't forget the -static-libgcc and -static-libstdc++ compile and link options, and do link to a _VERY_ old glibc, or your game binaries won't run on not that much older glibcs than the one you did link with (last time it happen to me: not more than 1.5 years, that's freaking short).
Glibc does not properly support static binaries, you need libc around even for static binaries mostly (eg dns resolution). Its annoying. You can make real static binaries with Musl libc though, or on the BSDs.
reply