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

211–215 of 215 posts

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

#211

Post by AshamedCaptain »

lmm wrote: post #210
AshamedCaptain wrote: post #206

Earlier quoted context omitted.

What effort exactly does it suggest? It ls literally dynamically linked with glbc.

It suggests someone went into the details of how it was linked and was careful about what it was and wasn't linked to, and perhaps even intervened directly in the low-level parts of the linking process.

Or rather it simply suggests you build for two versions of the major distributions of then, or the two distributions even...

Why is my entire argument so hard to understand? To build for a different glibc you do not have to do _any_ type of arcane magic or whatever you claim. You just build in a different system... or chroot... I have been doing that _myself_ for at least 15 years, and I know of other Linux desktop commercial shops that have been doing it for much, much longer. Chroots are _trivial_.

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

#212

Post by Splizard »

leni536 wrote: post #157
Splizard wrote: post #144

Earlier quoted context omitted.

You have to tell musl to use mmap instead of brk. You're right that it doesn't work in all cases but as long as you switch TLS on calls (and callbacks), at least with a project the size of Godot, you can approach a workable solution.

> You have to tell musl to use mmap instead of brk. How do I do that? Is there a documented configuration of musl's allocator?

you can patch musl, to initialize the brk state as -1 and then it won't use it.

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

#213

Post by markus92 »

AshamedCaptain wrote: post #160
markus92 wrote: post #158

Earlier quoted context omitted.

We (small HPC system) just upgraded our OS from RHEL 7 to RHEL 9. Most user apps are dynamically linked, too. You don't want to believe how many old binaries broke. Lot of ABI upgrades like libpng, ncurses, heck even stuff like readline and libtiff all changed just enough for linker errors to occur. Ironically all the statically compiled stuff was fine. Some small things like you mention only linking to glibc and X11…

> Funnily enough grabbing some old .so files from the RHEL 7 install and dumping them into LD_LIBRARY_PATH also worked better than expected. Why "better than expected"? I can run the entire userspace from Debian Etch on a kernel built two days ago... some kernel settings need to be changed (because of the old glibc! but it's not glibc's fault: it's the kernel who broke things), but it works. > Now running stuff compi…

Better than expected as it's mixing userlands. We didn't put the entire /usr/lib of the old system in LD_LIBRARY_PATH but just some stuff like old libpng, libjpeg and the shebang. Taking an image of an old compute node still on RHEL 7 and then dumping it a container naturally worked, but at that point it's only the kernel interface you have to worry about, not different glibc, gtk, qt and that kind of stuff.

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

#214

Post by vv_ »

diego_sandoval wrote: post #190
vv_ wrote: post #38

Earlier quoted context omitted.

It's easier to distribute software fully self-contained, if you ignore the pain of statically linking everything together :)

What's the pain?

Most open source software tooling Were designed to be dynamically linked. It is non-standard to statically link things together, which causes various random issues.

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

#215

Post by saghm »

a022311 wrote: post #132
saghm wrote: post #114

Earlier quoted context omitted.

IMO one of the best features of AppImage is that it makes it easy to extract without needing external tools. It's usually pretty easy for me to look at an AppImage and write a PKGBUILD to make a native Arch package; the format already encodes what things need to be installed where, so it's only a question of whether the libraries it contains are the same versions of what I can pull in as dependencies (either from the…

I agree. I've seen quite a few AUR packages built that way and I'm using a few myself too. The end user shouldn't be expected to do this though! :D

I agree with you as well! I don't think AppImage is perfect by any means. I do prefer it overall to the other commonly mentioned "universal" package tools like snap and flatpak, but I think my ideal system would essentially be a middleware protocol between build tool "frontends" and package format "backends" and then an ecosystem of tooling around that. LLVM and LSP haven't magically solved every issue with compilers and editor support for languages by any means, but they have significantly moved the needle on the average experience for quite a large number of end users even if they never directly touch any of the underlying protocols.
Post reply on HN