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

181–190 of 215 posts

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

#181

Post by jcalvinowens »

saidinesh5 wrote: post #165
jcalvinowens wrote: post #115

Earlier quoted context omitted.

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.

> You're supposed to do this recursively

ldd works recursively.

> Not to mention all the files from /usr/share

Well yeah, there obviously cannot be a generic way to enumerate all the files a program might open...

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

#182

Post by AshamedCaptain »

marcosdumay wrote: post #179
AshamedCaptain wrote: post #174

Earlier quoted context omitted.

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

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

No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k.

If you use VC++6 in 7, then yes, you can; but that's not really that different from me using a Debian Etch chroot to build.

Even within XP era this happens, since there are VS versions that target XP _SP2_ and produce binaries that are not compatible with XP _SP1_. That's the "DecodePointer" debacle I was mentioning. _Even_ if you do not use any "SP2" feature (as few as they are), the runtime (the statically linked part; not MSVCRT) is going to call DecodePointer, so even the smallest hello world will catastrophically fail in older win32 version.

Just Google around for hundreds of confused developers.

> Except that the older glibc is unmaintained and very hard to get a hold of and use.

"unmaintained" is another way of saying "frozen" or "security updates only" I guess. But ... hard to get a hold of ? You are literally running it on your the "security updates only" server that you wanted to target in the first place!

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

#183

Post by tonymet »

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…

can you write up a blog of how this is working? because both as a publisher and a user, broken binaries are much more the norm

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

#184

Post by VikingCoder »

tgittos wrote: post #180
VikingCoder wrote: post #88

Earlier quoted context omitted.

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.

I've got it working. Used Mongoose. Unfortunately Actually Portable Executables seem to not play well with WSL, and the suggested fixes didn't work. I'm able to play with it in a VM. Not as portable as I'd hoped, but I'll see how it goes.

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

#185

Post by [deleted] »

sebastos wrote: post #173
flohofwoe wrote: post #62

Earlier quoted context omitted.

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?

[deleted]

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

#186

Post by throwaway2046 »

AshamedCaptain wrote: post #155
flohofwoe wrote: post #62

Earlier quoted context omitted.

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…

> (e.g. not being able to run an executable that was created on a more recent Linux system on an older Linux system even when the program doesn't access any new glibc entry points - the usually adviced solution is to link with an older glibc version, but that's also not trivial, unless you use the Zig toolchain). In the era of containers, I do not understand why this is "Not trivial". I could do it with even a chroot…

Linking against an older glibc means setting up an older distribution and accepting all the outdated toolchains and libraries that come with it. Need to upgrade? Get ready to compile everything from source and possibly bootstrap a toolchain. I wouldn't call this trivial.

The fact that you need to use a container/chroot on Linux in the first place makes the process non trivial, when all you have to do on Windows is click a button or two.

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

#187

Post by CSm1n »

AshamedCaptain wrote: post #182
marcosdumay wrote: post #179

Earlier quoted context omitted.

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.

> 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. No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k. If you use VC++6 in 7, then yes, you can; but that's not really that different from me using a Debian Et…

> No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k.

Yes, you can! There are even multiple Windows 10 era toolchains that officially support XP. VS 2017 was the last release that could build XP binaries.

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

#188

Post by AshamedCaptain »

CSm1n wrote: post #187
AshamedCaptain wrote: post #182

Earlier quoted context omitted.

> 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. No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k. If you use VC++6 in 7, then yes, you can; but that's not really that different from me using a Debian Et…

> No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k. Yes, you can! There are even multiple Windows 10 era toolchains that officially support XP. VS 2017 was the last release that could build XP binaries.

"Without following any special procedure". I know you can install older toolchains and then build using those, but I can do as much on any platform (e.g. by using a chroot). The default on VS2012 is Vista-only binaries.

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

#189

Post by AshamedCaptain »

throwaway2046 wrote: post #186
AshamedCaptain wrote: post #155

Earlier quoted context omitted.

> (e.g. not being able to run an executable that was created on a more recent Linux system on an older Linux system even when the program doesn't access any new glibc entry points - the usually adviced solution is to link with an older glibc version, but that's also not trivial, unless you use the Zig toolchain). In the era of containers, I do not understand why this is "Not trivial". I could do it with even a chroot…

Linking against an older glibc means setting up an older distribution and accepting all the outdated toolchains and libraries that come with it. Need to upgrade? Get ready to compile everything from source and possibly bootstrap a toolchain. I wouldn't call this trivial. The fact that you need to use a container/chroot on Linux in the first place makes the process non trivial, when all you have to do on Windows is cl…

Wouldn't you target whatever is the minimum "supported" glibc you want to run in the first place? What is that you need to recompile?

Chroot _is_ trivial. I actually use it for convenience, as I could also as well install the older toolchains directly on the newer system, but chroot is just plain easier. Maybe VS has a button where you can target whatever version MS fancies today ("for a limited time offer"), but what about _any other_ windows toolchain?

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

#190

Post by diego_sandoval »

vv_ wrote: post #38
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.

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

What's the pain?
Post reply on HN