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

71–80 of 145 posts

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

#71

Post by cozzyd »

myk9001 wrote: post #48
cozzyd wrote: post #20

Earlier quoted context omitted.

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.

For Ubuntu they would only target LTS releases, most likely.

On EL it's easier, now you would just support 2 or 3 of EL7, EL8, and EL9.

As an example of something I use, Xfdtd only officially supports one version of Ubuntu and 2 versions of EL https://www.remcom.com/system-requirements#xfdtd-system-requ...

In practice, it wasn't too hard to get it running on EL9 or Fedora either...

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

#72

Post by charcircuit »

mikepavone wrote: post #66

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

>then complain entirely about glibc

You can ship all of your of the libraries you use with your executable. This isn't possible to do with glibc. It's the exception which is why it's talked about the most.

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

#73

Post by 2mlWQbCK »

moron4hire wrote: post #41
evidencetamper wrote: post #34

Earlier quoted context omitted.

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.

Old DOS games are often sold (e.g. on GOG or Steam) with an installer and a full copy of DOSBox, so you get an entire operating system plus hardware emulator to run the game. Looks like this adds less than 10 MB to each game installed in Windows.

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

#74

Post by mikepavone »

fooblaster wrote: post #67
mikepavone wrote: post #66

So 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?

The PEP-600 [0] Rationale section touches on this a bit. The basic problem is that there are things beyond glibc that would be nice to use from the environment for a number of reasons (security updates, avoiding clashes between multiple wheels that depend on the same lib, etc.), but since most libs outside of glibc and libstdc++ don't really have an ABI policy and the distros don't necessarily have a policy on what libraries are guaranteed to be present you sort of have to guess and hope for the best. While the initial list in PEP-513 [1] was a pretty good guess, one of the libraries chosen (libcrypt.so.1) got dropped in Fedora 30 and replaced with an ABI incompatible version. Crypto libraries are an example of something that's actually important to keep up to date so I find this rather unfortunate.

[0] https://peps.python.org/pep-0600/

[1] https://peps.python.org/pep-0513/

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

#75

Post by James_K »

m463 wrote: post #51
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…

the first launch of firefox would take a few hours. let alone the first boot of the linux kernel... :)

Just because you are used to slow compilers doesn't mean fast ones are impossible. As I said in the original post, code optimisation can be done before compilation on the developers machine, so all that need be done on the target is a simple debug build. An example is Jonathon Blow's JAI compiler which compiles around 250,000 lines of code per second. Even on very slow hardware this is reduced to perhaps 80,000LoC/s, two minutes for 10 million lines of code. Most users would be tolerant of an "install" box with a progress bar that takes at most two minutes for only the largest application on the computer. Or perhaps the browser people would opt not to distribute their software in this way. Advanced software may have advanced needs, beyond that of the average application. Most code is already written in Javascript these days, meaning it begins life being interpreted and is JIT compiled on the user's computer. Few seem to notice the compilation but many complain about the general sluggishness.

If you offered users a deal: spend 1 minute installing the software and it is snappy and responsive when you use it, I suspect all would accept.

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

#76

Post by James_K »

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.

The idea is that software would only be shipped if it actually works, and part of this would be ensuring it compiles. I'm not suggesting we use Make files or some other foul approach like that. Code should ideally be distributed as a single zip file with an executable header that triggers it to be unpacked in some cache directory by a program analogous to the linker, and compiled by the simple process of compiling all source files. Additionally this could be sped up drastically by having the compiler be a single executable with uniform flags across files. Header files could be parsed once and shared between build threads in parallel, which alone would safe much work on the part of the compiler. If this still proves insufficient, a language with superior semantics to C could be chosen which can be compiled faster. Most code these days shipped is JS which is compiled on the user's computer. This would be an order of magnitude improvement on that from a performance perspective.

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

#77

Post by mikepavone »

charcircuit wrote: post #72
mikepavone wrote: post #66

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

>then complain entirely about glibc You can ship all of your of the libraries you use with your executable. This isn't possible to do with glibc. It's the exception which is why it's talked about the most.

> It's the exception which is why it's talked about the most.

It's definitely not the only exception. libgl is another obvious example since different GPUs need different userland code. I would be surprised if there there had never been compat regressions in those.

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

#78

Post by forrestthewoods »

mikepavone wrote: post #66

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

> then complain entirely about glibc

That’s because when you’re trying to ship a product glibc is one of the primary sources of pain.

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

#80

Post by h4ck_th3_pl4n3t »

Isn't the compatibility promise what syscalls essentially are?

Historically, they (almost) never break and they are steadily incremented to prevent overlaps in differences of parameters.

As WASI is also implementing syscalls for WASM, I'd argue that the binary format doesn't really matter as long as it's using the same syscalls in the end.

I understand this topic is mostly focussing on glibc/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.

C ABI compatibility is a mess on linux mostly because upstream maintainers don't give a damn about semantic versioning. Just take a look at the SO file headers, and how they differ from upstream "semantic" versions of the library. As long as shared objects differ in versions due to breaking changes, and as long as the C ecosystem doesn't enforce correct versioning, this won't change.

Post reply on HN