Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jangafx.com

Post reply on HN
Print view View original

41–50 of 145 posts

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

#41

Post by moron4hire »

evidencetamper wrote: post #34
AshamedCaptain wrote: post #25

Earlier 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.

It's interesting to think how a 20 year old OS plus one program is probably a smaller bundle size than many modern Electron apps ostensibly built "for cross platform compatibility". Maybe microkernels are the way.

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

#43

Post by RedShift1 »

James_K wrote: post #32

Here'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'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 moder…

I hate compiling. 9/10 something goes wrong. Sometimes I can fix it, other times I just abandon the effort and use something else. These days I just use packages or docker images and if that doesn't work out I'm moving on, ain't nobody got time for this. You really can't expect people who just want to use their computers and don't even know what a compiler is to get involved in a process like that.

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

#44

Post by myk9001 »

AshamedCaptain wrote: post #30
forrestthewoods wrote: post #21

Earlier 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.

So maybe the difference here is between can and actually doing it?

I tend to stay on the oldest supported version of Windows until they drop support and haven't ever seen an application that wouldn't run because it's built on a newer version of Windows.

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

#45

Post by gosub100 »

forrestthewoods wrote: post #18
Jeaye wrote: post #14

I don't understand why they don't just statically link their binaries. First, they said this: > 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. But then they immediately said they actually statically link all of their deps aside from libc. > Instead, we take a different approach: statically linking everything we c…

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.

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

#46

Post by ses1984 »

RedShift1 wrote: post #43
James_K wrote: post #32

Here'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'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 moder…

I hate compiling. 9/10 something goes wrong. Sometimes I can fix it, other times I just abandon the effort and use something else. These days I just use packages or docker images and if that doesn't work out I'm moving on, ain't nobody got time for this. You really can't expect people who just want to use their computers and don't even know what a compiler is to get involved in a process like that.

No, end users need not get involved, it could/should be handled by the operating system.

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

#47

Post by veqq »

BwackNinja wrote: post #36

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. 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…

> 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 have fond memories of installed Warlords Battle Cry 3, Warcraft 3, AOE2 etc. directories on flash drives, distributed to 20+ kids in high school (all using the same key). Good days.

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

#48

Post by myk9001 »

cozzyd wrote: post #20
FitCodIa wrote: post #9

Earlier quoted context omitted.

> a lot of user-space in Linux-land does not make the same effort I believe that, what the article misses is that glibc is maintained and extended with an entirely different community and development model. Windows remains compatible over decades because Microsoft (a) is the sole distributor, and (b) puts an immense effort towards backwards compat. In Linux userspace, it's simply a non-goal across distributions. If y…

The big Linux distros (EL, Ubuntu) in fact have the opposite incentive, to get proprietary vendors to rather their distribution specifically.

This theory would check out if a proprietary vendor could easily get away with shipping a single binary package for all supported versions of, say, Ubuntu.

Having to build and maintain a binary packege separately for each version of the same distro probably isn't that appealing to them.

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

#49

Post by yjftsjthsd-h »

FitCodIa wrote: post #9
api wrote: post #3

Earlier quoted context omitted.

Is there a reason glibc can't just do a better job at keeping some legacy symbols around? It's not like it's big stuff. They're things like legacy string functions. We're talking a few kilobytes of code in most cases. The Linux kernel goes to a lot of effort to not break user space, at least for non-exotic core features and syscalls. It seems like a lot of user-space in Linux-land does not make the same effort. It's…

> a lot of user-space in Linux-land does not make the same effort I believe that, what the article misses is that glibc is maintained and extended with an entirely different community and development model. Windows remains compatible over decades because Microsoft (a) is the sole distributor, and (b) puts an immense effort towards backwards compat. In Linux userspace, it's simply a non-goal across distributions. If y…

> If you (as a commercial ISV) target a commercial distro with long-term support, and can convince your users to use / license the same distro, you'll have a good, stable development experience. You only need to port like once every decade, when you jump major releases.

If things go well, it's even better than that: If you target ex. RHEL 8, there's a very good chance that your binaries will work on RHEL 9 and a decent shot at RHEL 10 with zero changes (though of course you should test all versions you want to work). And the same for Ubuntu 20.04/22.04/24.04/... and Debian/SUSE/whatever. Backwards incompatibilities can happen, but within a single stable distro they're not super common so the lazy ISV can probably only really port forward after more than a decade if they really want.

(Incidentally, this isn't a hypothetical: I once had the joy of working on software that targeted RHEL 5, and those binaries ran on RHEL/CentOS 7 without any problems.)

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

#50

Post by pmarreck »

moron4hire wrote: post #40
jll29 wrote: post #39

> 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…

What about the security issues of the old operating systems people keep around for their mission critical software that has no upgrade path?

isn't this tu quoque?
Post reply on HN