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

The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

github.com

Post reply on HN
Print view View original

171–180 of 215 posts

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#171

Post by rlpb »

saidinesh5 wrote: post #169
rlpb wrote: post #140

Earlier quoted context omitted.

Debian manages perfectly well without.

Only because of the enormous efforts put in by debian package maintainers and it's infrastructure. If you're a an indie developer wanting your application to run on various debian based distros but the debian maintainers won't package your application, that's when you'd see why it's called DLL hell, how horribly fragmented the Linux packaging is and why even steam ships their whole run time.

Everything inside Debian is fine. That's most of the ecosystem apart from the very new stuff that isn't mature enough yet. Usually the reason something notable stays out if Debian long term is when that thing has such bad dependency hygiene that it cannot easily be brought up to standard.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#172

Post by marcosdumay »

AshamedCaptain wrote: post #162
marcosdumay wrote: post #161

Earlier quoted context omitted.

The problem of modern libc (newer than ~2004, I have no idea what that 1996 one is doing) isn't that old software stops working. It's that you can't compile software on your up to date desktop and have it run on your "security updates only" server. Or your clients "couple of years out of date" computers. And that doesn't require using newer functionality.

But this is not "backwards compatibility". No one promises this type of "forward compatibility" that you are asking for . Even win32 only does it exceptionally... maybe today you can still build a win10 binary with a win11 toolchain, but you cannot build a win98 binary with it for sure. And this has nothing to do with 1996, or 2004 glibc at all. In fact, glibc makes this otherwise impossible task actually possible: y…

Windows dlls are forward compatible in that sense. If you use the Linux kernel directly, it is forward compatible in that sense. And, of course, there is no issue at all with statically linked code.

The problem is with the Linux dynamic linking, and the idea that you must not statically link the glibc code. And you can circumvent it by freezing your glibc abstraction interface, so that if you need to add another function, you do so by making another library entirely. But I don't know if musl does that.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#173

Post by sebastos »

flohofwoe wrote: post #62
mgaunard wrote: post #36

It's funny how people insist on wanting to link everything statically when shared libraries were specifically designed to have a better alternative. Even worse is containers, which has the disadvantage of both.

Dynamic libraries make a lot of sense as operating system interface when they guarantee a stable API and ABI (see Windows for how to do that) - the other scenarios where DLLs make sense is for plugin systems. But that's pretty much it, for anything else static linking is superior because it doesn't present an optimization barrier (especially for dead code elimination). No idea why the glibc can't provide API+ABI stab…

Genuine question - are there examples (research? old systems?) of the interface to the operating system being exposed differently than a library? How might that work exactly?

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#174

Post by AshamedCaptain »

marcosdumay wrote: post #172
AshamedCaptain wrote: post #162

Earlier quoted context omitted.

But this is not "backwards compatibility". No one promises this type of "forward compatibility" that you are asking for . Even win32 only does it exceptionally... maybe today you can still build a win10 binary with a win11 toolchain, but you cannot build a win98 binary with it for sure. And this has nothing to do with 1996, or 2004 glibc at all. In fact, glibc makes this otherwise impossible task actually possible: y…

Windows dlls are forward compatible in that sense. If you use the Linux kernel directly, it is forward compatible in that sense. And, of course, there is no issue at all with statically linked code. The problem is with the Linux dynamic linking, and the idea that you must not statically link the glibc code. And you can circumvent it by freezing your glibc abstraction interface, so that if you need to add another func…

> Windows dlls are forward compatible in that sense.

If you want to go to such level, ELF is also forward compatible in that sense.

This is completely irrelevant, because what the developer is going to see is the binaries he builts in XP SP3 no longer work in XP SP2 because of a link error: the _statically linked_ runtime is going to call symbols that are not in XP SP2 DLLs (e.g. the DecodePointer debacle).

> If you use the Linux kernel directly, it is forward compatible in that sense.

Or not, because there will be a note in the ELF headers with the minimum kernel version required, which is going to be set to a recent version even if you do not use any newer feature. (unless you play with the toolchain) (PE has similar field too, leading to the "not a valid win32 executable" messages).

> And, of course, there is no issue at all with statically linked code.

I would say statically linked code is precisely the root of all these problems.

In addition to bring more problems of its own. E.g. games that dynamically link with SDL can be patched to have any other SDL version, including one with bugfixes for X support, audio, etc. Games that statically link with SDL? Sorry..

> And you can circumvent it by freezing your glibc abstraction interface, so that if you need to add another function, you do so by making another library entirely. But I don't know if musl does that.

Funnily, I think that is exactly the same as the solution I'm proposing for this conundrum: just (dynamically) link with the older glibc ! Voila: your binary now works with glibc from 1996 and glibc from 2026.

Frankly, glibc is already the project with the best binary compatibility of the entire Linux desktop , if not the only one with a binary compatibility story at all . The kernel is _not_ better in this regard (e.g. /dev/dsp).

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#175

Post by ranger_danger »

holowoodman wrote: post #74
arghwhat wrote: post #47

Earlier quoted context omitted.

Dynamic libraries have been frowned upon since their inception as being a terrible solution to a non-existent problem, generally amplifying binary sizes and harming performance. Some fun quotes of quite notable characters on the matter here: https://harmful.cat-v.org/software/dynamic-linking/ In practice, a statically linked system is often smaller than a meticulously dynamically linked one - while there are many cop…

Statically linked binaries are a huge security problem, as are containers, for the same reason. Vendors are too slow to patch. When dynamically linking against shared OS libraries, Updates are far quicker and easier. And as for the size advantage, just look at a typical Golang or Haskell program. Statically linked, two-digit megabytes, larger than my libc...

Would be nice if there was a binary format where you could easily swap out static objects for updated ones

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#176

Post by dekhn »

johndough wrote: post #103
rafale wrote: post #87

Earlier quoted context omitted.

"All problems in computer science can be solved by another level of indirection"

"... except for the problem of too many levels of indirection."

that's solved with an off-by-one error

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#177

Post by fdgdd »

amelius wrote: post #5

Is there a tool that takes an executable, collects all the required .so files and produces either a static executable, or a package that runs everywhere?

Exodus (https://github.com/intoli/exodus) used to be good for this but is giving me a Python error these days.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#178

Post by m463 »

joshmarinacci wrote: post #123
drowsspa wrote: post #116

Earlier quoted context omitted.

I find it amazing how much the mess that building C/C++ code has been for so many decades seems to have influenced the direction technology, the economy and even politics has been going. Really, what would the world look like if this problem had been properly solved? Would the centralization and monetization of the Internet have followed the same path? Would Windows be so dominant? Would social media have evolved to…

How does this technical issue affect the economy and politics? In what way would the world be different just because we used a better linker?

Well, you could just look at things from an interoperability and standards viewpoint.

Lots of tech companies and organizations have created artificial barriers to entry.

For example, most people own a computer (their phone) that they cannot control. It will play media under the control of other organizations.

The whole top-to-bottom infrastructure of DRM was put into place by hollywood, and then is used by every other program to control/restrict what people do.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#179

Post by marcosdumay »

AshamedCaptain wrote: post #174
marcosdumay wrote: post #172

Earlier quoted context omitted.

Windows dlls are forward compatible in that sense. If you use the Linux kernel directly, it is forward compatible in that sense. And, of course, there is no issue at all with statically linked code. The problem is with the Linux dynamic linking, and the idea that you must not statically link the glibc code. And you can circumvent it by freezing your glibc abstraction interface, so that if you need to add another func…

> Windows dlls are forward compatible in that sense. If you want to go to such level, ELF is also forward compatible in that sense. This is completely irrelevant, because what the developer is going to see is the binaries he builts in XP SP3 no longer work in XP SP2 because of a link error: the _statically linked_ runtime is going to call symbols that are not in XP SP2 DLLs (e.g. the DecodePointer debacle). > If you…

If you use only features available on the older version, for sure, you can compile your software in Win-7 and have it run in Win-2000. Without following any special procedure.

I know, I've done that.

> just (dynamically) link with the older glibc!

Except that the older glibc is unmaintained and very hard to get a hold of and use. If you solve that, yeah, it's the same.

Re: The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

#180

Post by tgittos »

VikingCoder wrote: post #88
Rochus wrote: post #60

So what we need is essentially a "libc virtualization". But Musl is only available on Linux, isn't it? Cosmopolitan ( https://github.com/jart/cosmopolitan ) goes further and is available also on Mac and Windows, and it uses e.g. SIMD and other performance related improvements. Unfortunately, one has to cut through the marketing "magic" to find the main engineering value; stripping away the "polyglot" shell-script hac…

I desperately want to write C/C++ code that has a web server and can talk websockets, and that I can compile with Cosmopolitan. I don't want Lua. Using Lua is crazy clever, but it's not what I want. I should just vibe code the dang thing.

You should, it’s fun.

I have a devcontainer running the Cosmopolitan toolchain and stuck the cosmocc README.md in a file referenced from my AGENTS.md.

Claude does a decent job. You have to stay on top of it when it’s writing C, easy to turn to spaghetti.

Also the fat binary concept trips up agents - just have it read the actual cosmocc file itself to figure any issues out.

Post reply on HN