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

161–170 of 215 posts

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

#161

Post by marcosdumay »

AshamedCaptain wrote: post #154
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…

What I find amazing is why people continously claim glibc is the problem here. I have a commercial software binary from 1996 that _still works_ to this day. It even links with X11, and works under Xwayland. The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb. At this point I think people just do not know how binary compatibility works at a…

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.

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

#162

Post by AshamedCaptain »

marcosdumay wrote: post #161
AshamedCaptain wrote: post #154

Earlier quoted context omitted.

What I find amazing is why people continously claim glibc is the problem here. I have a commercial software binary from 1996 that _still works_ to this day. It even links with X11, and works under Xwayland. The trick? It's not statically linked, but dynamically linked. And it doesn't like with anything other than glibc, X11 ... and bdb. At this point I think people just do not know how binary compatibility works at a…

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: you can force to link with older symbols, but that solves only a fraction of the problem of what you're trying to achieve. Statically linking / musl does not solve this either. At some point musl is going to use a newer syscall, or any other newer feature, and you're broke again.

Also, what is so hard about building your software in your "security updates only" server? Or a chroot of it at least ? As I was saying below, I have a Debian 2006-ish chroot for this purpose....

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

#163

Post by saidinesh5 »

amelius wrote: post #20
TheDong wrote: post #11

Earlier quoted context omitted.

There are things like this. The things I know of and can think of off the top of my head are: 1. appimage https://appimage.org/ 2. nix-bundle https://github.com/nix-community/nix-bundle 3. guix via guix pack 4. A small collection of random small projects hardly anyone uses for docker to do this (i.e. https://github.com/NilsIrl/dockerc ) 5. A docker image (a package that runs everywhere, assuming a docker runtime is a…

AppImage looks like what I need, thanks. I wonder though, if I package say a .so file from nVidia, is that allowed by the license?

Typically appimage packaging excludes the .so files that are expected to be provided by the base distro.

Any .so from nvidia is supposed to be one of those things. Because it also depends on the drivers etc.. provided by nvidia.

Also on a side note, a lot of .so files also depends on other files in /usr/share , /etc etc...

I recommend using an AppImage only for the happy path application frameworks they support (eg. Qt, Electron etc...). Otherwise you'd have to manually verify all the libraries you're bundling will work on your user's distros.

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

#164

Post by yxhuvud »

rlpb wrote: post #95
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…

Imagine a fully statically linked version of Debian. What happens when there’s a security update in a commonly used library? Am I supposed to redownload a rebuild of basically the entire distro every time this happens, or else what?

Honestly, that doesn't sound too bad if you have decent bandwidth.

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

#165

Post by saidinesh5 »

jcalvinowens wrote: post #115
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?

mkdir chroot cd chroot for lib in $(ldd ${executable} | grep -oE '/\S+'); do tgt="$(dirname ${lib})" mkdir -p .${tgt} cp ${lib} .${tgt} done mkdir -p .$(dirname ${executable}) cp ${executable} .${executable} tar cf ../chroot-run-anywhere.tgz .

You're supposed to do this recursively for all the libs no?

Eg. Your App might just depend on libqt5gui.so but that libqt5gui.so might depend on some libxml etc...

Not to mention all the files from /usr/share etc... That your application might indirectly depend on.

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

#166

Post by sidewndr46 »

cwillu wrote: post #107
binsquare wrote: post #102

Earlier quoted context omitted.

I'm building in this space, I take a docker inside a microvm (vm-lite) approach. https://github.com/smol-machines/smolvm

And the cycle continues

I wonder if inside the docker container we can run a sandboxed WASM runtime?

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

#167

Post by sidewndr46 »

leeter wrote: post #153
sidewndr46 wrote: post #80

Earlier quoted context omitted.

Aren't all DLLs on the Windows platform compiled with an unusual instruction at the start of each function? This makes it possible to somehow hot patch the DLL after it is already in memory

I believe you're thinking of the x86 Hotpatching hook[1], which doesn't exist on x86-64[2] (in the same form, it uses a x86-64 safe one). [1] https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=95... [2] https://devblogs.microsoft.com/oldnewthing/20221109-00/?p=10...

yes, that's it. Thanks for clarifying

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

#168

Post by mgaunard »

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…

Static linking is also an optimization barrier.

LTO is really a different thing, where you recompile when you link. You could technically do that as part of the dynamic linker too, but I don't think anyone is doing it.

There is a surprisingly high number of software development houses that don't (or can't) use LTO, either because of secrecy, scalability issues or simply not having good enough build processes to ensure they don't breach the ODR.

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

#169

Post by saidinesh5 »

rlpb wrote: post #140
throwaway2046 wrote: post #109

Earlier quoted context omitted.

Libraries already break their ABI so often that continuously rebuilding/relinking everything is inevitable.

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.

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

#170

Post by sebastos »

uecker wrote: post #145
abigail95 wrote: post #100

Earlier quoted context omitted.

Why would I want to be constantly calling into code I have no control over, that may or may not exist, that may or may not be tampered with. I lose control of the execution state. I have to follow the calling conventions which let my flags get clobbered. To forego all of the above including link time optimization for the benefit of what exactly? Imagine developing a C program where every object file produced during c…

You call into dynamic libraries so that you do not need to recompile and distribute new binaries to all your users whenever there is a security issue or other critical fix in any of the dependencies.

But if I get to Bring My Own Dependencies, then I know the exact versions of all my dependencies. That makes testing and development faster because I don’t have to expend effort testing across many different possible platforms. And if development is just generally easier, then maybe it’s easier to react expediently to security notices and release updates as necessary.. .
Post reply on HN