The state of binary compatibility on Linux and how to address it

So of the 3 glibc issues they link<p>- 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<p>- 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)<p>- 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<p>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.<p>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.

There 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.<p>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 incentive and ability for downstream (or users) to upgrade those dependencies.<p>The libc stuff in this article is mostly glibc-specific, and you&#x27;d have fewer issues targeting musl. Mixing static linking and dlopen doesn&#x27;t make much sense, as said here[1] which is an interesting thread. Even dns resolution on glibc implies dynamic linking due to nsswitch.<p>Solutions like Snap, Flatpak, and AppImage work to contain the problem by reusing the same abstractions internally rather than introducing anything that directly addresses the issue. We won&#x27;t have a clean solution until we collectively abandon the FHS for a decentralized filesystem layout where adding an application (not just a program binary) is as easy as extracting a package into a folder and integrates with the rest of the system. I&#x27;ve worked on this off and on for a while, but being so opinionated makes everything an uphill battle while accepting the current reality is easy.<p>[1] <a href="https:&#x2F;&#x2F;musl.openwall.narkive.com&#x2F;lW4KCyXd&#x2F;static-linking-and-dlopen" rel="nofollow">https:&#x2F;&#x2F;musl.openwall.narkive.com&#x2F;lW4KCyXd&#x2F;static-linking-an...</a>

As an end user I often patch the glibc version incompatibility away with <a href="https:&#x2F;&#x2F;github.com&#x2F;corsix&#x2F;polyfill-glibc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;corsix&#x2F;polyfill-glibc</a><p><pre><code> $ .&#x2F;polyfill-glibc --target-glibc=2.17 &#x2F;path&#x2F;to&#x2F;my-program </code></pre> This often leads to discovering <i>new</i> version incompatibilities in other libs. But as the article says others usually <i>can</i> be statically compiled.

I don&#x27;t understand why they don&#x27;t just statically link their binaries. First, they said this:<p>&gt; Even if you managed to statically link GLIBC—or used an alternative like musl—your application would be unable to load any dynamic libraries at runtime.<p>But then they immediately said they actually statically link all of their deps aside from libc.<p>&gt; Instead, we take a different approach: statically linking everything we can.<p>If they&#x27;re statically linking everything other than libc, then using musl or statically linking glibc will finish the job. Unless they have some need for loading share libs at runtime which they didn&#x27;t already have linked into their binary (i.e. manual dlopen), this solves the portability problem on Linux.<p>What am I missing (assuming I know of the security implications of statically linked binaries -- which they didn&#x27;t mention as a concern)?

Windows having multiple C libraries has its own pain points, in particular it&#x27;s difficult to ship binary libraries that return allocated memory to their consumer (you either need to have the library consumer allocate the memory, which probably explains why so many Win32 APIs have this behaviour, or allow alloc&#x2F;free functions to be registered). Not to mention different C libraries having their own file handle, TLS, etc state. Unsurprisingly Microsoft now ships the Universal CRT (UCRT) as part of Windows.

This is a really great article about binary compatibility!<p>I disagree with their idea for fixing it by splitting up glibc. I think it&#x27;s a bad idea because it doesn&#x27;t actually fix the problems that lead to compat breakage, and it&#x27;s bad because it&#x27;s harder than it seems.<p>They cite these compat bugs as part of their reasoning for why glibc should be split up:<p>- <a href="https:&#x2F;&#x2F;sourceware.org&#x2F;bugzilla&#x2F;show_bug.cgi?id=29456" rel="nofollow">https:&#x2F;&#x2F;sourceware.org&#x2F;bugzilla&#x2F;show_bug.cgi?id=29456</a><p>- <a href="https:&#x2F;&#x2F;sourceware.org&#x2F;bugzilla&#x2F;show_bug.cgi?id=32653" rel="nofollow">https:&#x2F;&#x2F;sourceware.org&#x2F;bugzilla&#x2F;show_bug.cgi?id=32653</a><p>- <a href="https:&#x2F;&#x2F;sourceware.org&#x2F;bugzilla&#x2F;show_bug.cgi?id=32786" rel="nofollow">https:&#x2F;&#x2F;sourceware.org&#x2F;bugzilla&#x2F;show_bug.cgi?id=32786</a><p>I don&#x27;t see how a single one of these would be fixed by splitting up glibc. If their proposed libdl or libthread were updated and had one of these regressions, it would cause just as much of a bug as if a monolithic libc updates with one of these regressions.<p>So, splitting up glibc wouldn&#x27;t fix the issue.<p>Also, splitting up glibc would be super nasty because of how the threading, loading, and syscall parts of libc are coupled (some syscalls are implemented with deep threading awareness, like the setxid calls, threads need to know about the loader and vice-versa, and other issues).<p>I think the problem here is how releases are cut. In an ideal world, glibc devs would have caught all three of those bugs before shipping 2.41. Big corpos like Microsoft manage that by having a binary compatibility team that runs All The Apps on every new version of the OS. I&#x27;m guessing that glibc doesn&#x27;t have (as much of) that kind of process.

I bought 3 linux games on DVD between 2006 and 2016. I stopped buying linux games and instead started again buying windows games. Because there is no easy way to run them. On the other hand I can just run myst1993 and most of windows games without much hustle via wine. Wine is linux only stable abi

<p><pre><code> &gt; 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, ever-changing libc. </code></pre> One of the questions of multiple versions on the same box is what about security issues of those older versions...

This article missed a critical point which is &quot;the right way&quot; to select a glibc ABI version: see binutils ld documentation, second part of the page related to VERSION support. This must include glibc internal symbols.<p>This will allow to craft ELF binaries on a modern distro which will run on &quot;older&quot; distros. This is critical for games and game engines. There is an significant upfront only-once work in order to select an &quot;old&quot; glibc ABI.<p>The quick and dirty alternative being having a toolchain configured to link with an &quot;old&quot; glibc on the side.<p>This article missed the -static-libstdc++ critical option for c++ applications (the c++ ABI is hell on earth), but did not miss the -static-libgcc and the dynamic loading of system interface shared libs.

I think the problem is that people treat Linux as OS instead of just a kernel.<p>You should assume every Linux distro is a different OS so when you are shipping your app for Linux you&#x27;re actually shipping your app for Debian, Fedora, Ubuntu etc

Zig CC + Vulkan would solve most of these issues:<p>1. Zig&#x27;s toolchain statically links with musl libc, producing binaries that depend only on the Linux kernel syscall ABI, not any specific glibc version.<p>2. This eliminates all the symbol versioning nightmares (`GLIBC_2.xx not found`) that plague distribution across different Linux systems.<p>3. Vulkan provides a standardized, vendor-neutral GPU API that&#x27;s supported across all modern graphics hardware, eliminating driver-specific dependencies.<p>4. The resulting binary is completely self-contained - no external library dependencies, no version mismatches, no containerization needed.<p>5. You get forward AND backward compatibility - the binary will run on both ancient and cutting-edge distros without modification.<p>The only real limitation is for NVIDIA CUDA-specific workloads, where you&#x27;d still need their proprietary stack.<p>Furthermore, for those who prefer a higher-level API, Zig CC + WebGPU offers similar benefits with a simpler programming model, though with slightly less mature implementations and a possible small performance overhead.

Isn&#x27;t the compatibility promise what syscalls essentially are?<p>Historically, they (almost) never break and they are steadily incremented to prevent overlaps in differences of parameters.<p>As WASI is also implementing syscalls for WASM, I&#x27;d argue that the binary format doesn&#x27;t really matter as long as it&#x27;s using the same syscalls in the end.<p>I understand this topic is mostly focussing on glibc&#x2F;muslc problems, but if you want to develop stable software, use CGo free Go binaries. They likely will run in 10 years the same way they do today.<p>C ABI compatibility is a mess on linux mostly because upstream maintainers don&#x27;t give a damn about semantic versioning. Just take a look at the SO file headers, and how they differ from upstream &quot;semantic&quot; versions of the library. As long as shared objects differ in versions due to breaking changes, and as long as the C ecosystem doesn&#x27;t enforce correct versioning, this won&#x27;t change.

&gt; GLIBC is an example of a &quot;system library&quot; 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.<p>Running WordPerfect on modern Linux is done by shipping both of those components:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;taviso&#x2F;wpunix" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;taviso&#x2F;wpunix</a>

There’s no reason to believe that widespread Linux adoption would not irrevocably damage the experience. It would end up looking something like Android. The same thing happened to the internet. It was ruined by mass adoption. You can call this gatekeeping, but nothing positive has come from getting most of the world onto social media.

No discussion of Cosmopolitan or APE?

I&#x27;m surprised nobody has mentioned the &quot;nix&quot; package manager from NixOS as an alternative here...

&gt; shipping software on Linux<p>That&#x27;s a surprisingly hard nut to crack when containers won&#x27;t work for your use case. We found <a href="https:&#x2F;&#x2F;github.com&#x2F;silitics&#x2F;rugix" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;silitics&#x2F;rugix</a> to work well in that situation.

golang seems to manage being 100% statically linked (unless you go out of your way, by using plugins). It just forgoes the stuff that the article mentions glibc doing dynamic linking for, and does it the simple and direct way.

Really the title should be something like “the difficulty of releasing binaries on Linux and how to work around it.” It isn’t really an atrocious state, the goal of a distro should be to get useful software into the repos. Software not distributed in an open source format doesn’t really help there.

Related video about releasing games on linux, i.e. dlopen() all the things <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=MeMPCSqQ-34" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=MeMPCSqQ-34</a>

Why don’t the authors release a distro that actually implements their own proposal?<p>Say, based on (perhaps on pieces of) musl, to be more straightforward to get things going?

Does Nix have any relevance here?

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.<p>Edit: Found it - it&#x27;s black on black - even worse!

Here&#x27;s a thought: just distribute source code. ABI issues should be mostly fixed. Most computers can compile source code fast enough for the user not to notice and cache the results so that it&#x27;s never a problem again. If you want optimised code, you can do a source to source optimisation then zip and minify the file. You could compile such a library to approximately native speeds without much user-end lag using modern JIT methods, and maybe even run LTO in a background thread so that the exectuables outdo dynamically linked ones.