Absolutely ridiculous that scrollbars are disabled for this page. The kids are too cool for such pedestrian web parts! Grow up and stop forcing your shitty UX on people.
Edit: Found it - it's black on black - even worse!
The state of binary compatibility on Linux and how to address it
61–70 of 145 posts
Re: The state of binary compatibility on Linux and how to address it
#62Earlier quoted context omitted.
> executables built and using a newer glibc It’s an abomination that Linux uses system libraries when building. Catastrophically terrible and stupid decision. It should be trivial for any program to compile and specify any arbitrary previous version of glibc as the target. Linux got this so incredibly wildly wrong. It’s a shame.
Ehm... you _can_ use the older toolchain even in the newer "Linux", in the same way you have to use a older Visual Studio to target Windows 8 from Windows 10.
I am saying that compiler toolchains on Linux should never ever under any circumstances ever rely on anything on the system for compiling. Compiling based on the system global version of glibc is stupid, bad, wrong, and Linus should be ashamed for letting it happen.
It should be trivial for Windows to cross-compile for Linux for any distro and for any ancient version of glibc.
It is not trivial.
Here is a post describing the mountain range of bullshit that Zig had to move to enable trivial cross-compile and backwards targeting. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
Linux is far and away the worst offender out of Linux, Mac, and Windows. By leaps and bounds.
Re: The state of binary compatibility on Linux and how to address it
#63Does Nix have any relevance here?
Re: The state of binary compatibility on Linux and how to address it
#64Earlier quoted context omitted.
musl and glibc static links are their own Pandora’s box of pain and suffering. They don’t “just work” like you’d hope and dream.
This blows my mind, that in 2025 we still struggle with a simple task such as "read in a string, parse it, and query a cascade of resolvers to discover it's IP". I just can't fathom how that is a difficult problem, or why DNS still is notorious for causing so much pain and suffering. Compared to the advancements in hardware and graphics and so many other areas.
There are resolvers for not just DNS but for users and other lookups. The list of resolvers is dynamic, they are configured in /etc/nsswitch.conf. The /etc/hosts lookup is part of the system.
Where do the resolvers come from? It needs to be possible to install resolvers separately and dynamically load them. Unless you want to have NIS always installed. Better to install LDAP for those who need it.
Re: The state of binary compatibility on Linux and how to address it
#65> More importantly, separating the dynamic linker from the C library itself would allow multiple versions of libc to coexist, eliminating a major source of compatibility issues. This is exactly how Windows handles it, which is one of the reasons Windows maintains such strong binary compatibility. You can still run decades-old Windows software today because Microsoft doesn’t force everything to be tied to a single, ev…
> Windows maintains such strong binary compatibility The REAL reason windows maintains binary compatibility is because it is commercial and nobody ships source code. In fact, many applications ship a whole boatload of DLLs, which I think is the commercial equivalent of static linking.
It kinda is, and kinda isn't.
It is, in the sense that the package is bigger, and the package ships "everything it needs".
It isn't in the sense that those parts can be updated independently as long as the DLL interface is backward compatible.
For example, I ship OpenSSL dlls with my app. Which means swapping in a later (compatible) OpenSSL can be done (by the user if necessary.)
If I'm making a small utility I static link it - and I still use utilities daily I compiled 25 years ago. Obviously those dynamically link to KERNEL etc, but Microsoft has insane levels of compatibility there.
And perhaps that's the fundamental root of the issue. Windows has one provider, very committed to the longevity of software. Linux, well, does not.
That's OK. The world has room for different philosophies. And each one will have strengths and weaknesses.
Re: The state of binary compatibility on Linux and how to address it
#66So of the 3 glibc issues they link
- one is about the format of symbol information in the actual ELF binaries which is only an issue if you are not using the standard libc functions for looking up symbols for some strange reason
- one is an issue that impacts targeting a lower version of glibc from a higher one which is a configuration that was never supported (though usually fails more loudly)
- the last one is a security policy change which is legitimately an ABI break, but mostly impacts programs that have their execstack flags set incorrectly
glibc actually goes to a fair bit of effort to be compatible with old binaries unlike most of the rest of the Linux userspace. The binaries I built for my side project back in 2015 (BlastEm 0.3.0) still work fine on modern Linux and they dynamically link against glibc. This is just a hobby project, not a piece of professional software, and a build from before this JangaFX company even existed works fine.
I find it really bizarre when people talk about Linux binary compat and then complain entirely about glibc rather than the sort of problems that the manylinux project has had to deal with. glibc is one of the few parts of userspace you can depend on. Yes, setting up your toolchain to build against an old glibc on a modern distro is a bit annoying. Sure, if you do something sufficiently weird you might find yourself outside what glibc considers part of their stable ABI. But from where I sit, it works pretty well.
Re: The state of binary compatibility on Linux and how to address it
#67So of the 3 glibc issues they link - one is about the format of symbol information in the actual ELF binaries which is only an issue if you are not using the standard libc functions for looking up symbols for some strange reason - one is an issue that impacts targeting a lower version of glibc from a higher one which is a configuration that was never supported (though usually fails more loudly) - the last one is a se…
Is there a good summary of the problems manylinux had to deal with?
Re: The state of binary compatibility on Linux and how to address it
#68There is no distinction between system and program libraries in Linux. We used to pretend there was one before usrmigration, but that was never good to take seriously. The distro as packager model ensures that everything is mixed together in the filesystem and is actively hostile to external packaging. Vendoring dependencies or static linking improves compatibility by choosing known working versions, but decreases in…
> Even dns resolution on glibc implies dynamic linking due to nsswitch. Because, as far as I’ve heard, it borrowed that wholesale from Sun, who desperately needed an application to show off their new dynamic linking toy. There’s no reason they couldn’t’ve done a godsdamned daemon (that potentially dynamically loaded plugins) instead, and in fact making some sort of NSS compatibility shim that does work that way (eith…
> The same applies to PAM word for word.
That's one of the reasons that OpenBSD is rather compelling. BSDAuth doesn't open arbitrary libraries to execute code, it forks and execs binaries so it doesn't pollute your program's namespace in unpredictable ways.
> It's true that there's something of a problem where two copies of a libc can't coexist in a process...
That's the meat of this article. It goes beyond complaining about a relatable issue and talks about the work and research they've done to see how it can be mitigated. I think it's a neat exercise to wonder how you could restructure a libc to allow multi-libc compatibility, but question why anyone would even want to statically link to libc in a program that dlopen's other libraries. If you're worried about a stable ABI with your libc, but acknowledge that other libraries you use link to a potentially different and incompatible libc thus making the problem even more complicated, you should probably go the BSDAuth route instead of introducing both additional complexity and incompatibility with existing systems. I think almost everything should be suitable for static linking and that Drepper's clarification is much more interesting than the rant. Polluting the global lib directory with a bunch of your private dependencies should be frowned upon and hides the real scale of applications. Installing an application shouldn't make the rest of your system harder to understand, especially when it doesn't do any special integration. When you have to dynamically link anyway:
> As for why you’d actually want to dlopen from a static executable, there’s one killer app: exokernels, loading (parts of) system-provided drivers into your process for speed.
If you're dealing with system resources like GPU drivers, those should be opaque implementations loaded by intermediaries like libglvnd. [1] This comes to mind as even more reason why dynamic dependencies of even static binaries are terrible. The resolution works, but it would be better if no zlib symbols would leak from mesa at all (using --exclude-libs and linking statically) so a compiled dependency cannot break the program that depends on it. So yes, I agree that dynamic dependencies of static libraries should be static themselves (though enforcing that is questionable), but I don't agree that the libc should be considered part of that problem and statically linked as well. That leads us to:
> ... when done right they don't even require both sides to share a malloc implementation
Better API design for libraries can eliminate a lot of these issues, but enforcing that is much harder problem in the current landscape where both sides are casually expected to share a malloc implementation -- hence the complication described in the article. "How can we force everything that exists into a better paradigm" is a lot less practical of a question than "what are the fewest changes we'd need to ensure this would work with just a recompile". I agree with the idea of a "narrow waist of an interface", but it's not useful in practice until people agree where the boundary should be and you can force everyone to abide by it.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28...
Re: The state of binary compatibility on Linux and how to address it
#69> GLIBC is an example of a "system library" that cannot be bundled with your application because it includes the dynamic linker itself. This linker is responsible for loading other libraries, some of which may also depend on GLIBC—but not always.
Running WordPerfect on modern Linux is done by shipping both of those components:
Re: The state of binary compatibility on Linux and how to address it
#70Earlier quoted context omitted.
And please, statically linking everything is NOT a solution -- the only reason I can run some games from 20 years ago still on my recent Linux is because they didn't decide to stupidly statically link everything, so I at least _can_ replace the libraries with hooks that make the games work with newer versions.
As long as the library is available. Neither static nor dynamic linking is looking to solve the 20 year old binaries issue, so both will have different issues. But I think it's easier for me to find a 20 year old ISO of a Red Hat/Slackware where I can simply run the statically linked binary. Dependency hell for older distros become really difficult when the older packages are not archived anywhere anymore.
Debian archives all of our binaries (and source) here:
Some things built on top of that:
https://manpages.debian.org/man/debsnap https://manpages.debian.org/man/debbisect https://wiki.debian.org/BisectDebian https://metasnap.debian.net/ https://reproduce.debian.net/