Hacker News Reader

Comment by moomin | Hacker News Reader

Biggest problem for musl isn't actually a problem _with_ musl at all, it's this: the C stdlib isn't an ABI. What this means is, something compiled for glibc doesn't necessarily work with musl and will just crash. This problem goes much further than you'd expect. For instance, if you use .NET 3.1 with Alpine, you can't use Google's gRPC client (thankfully, you can use Microsoft's).

View on HN

I see similar issues with devs trying to use pre-compiled (originally w/glibc) JVMs with Alpine. There are musl built JVMs, but the dev teams seem unaware musl is even there.

Distros that use musl make my life quantifiably worse for this reason.

It actually bit me on the ass a couple weeks ago when installing a rust binary instead of using cargo --install because it shaved ~10 minutes off running a CI pipeline. Had to fall back because the rust bin wasn't linked against musl libc when it was compiled for unknown Linux targets, and the authors don't distribute a musl compatible binary.

This actually goes further than that as different version of glibc aren't ABI compatible with one another.

They are backwards-compatible (which is all you can do of course).

Are they ?

If seen my share of old x64 binaries refusing to run on modern linux distro, spouting some sort of undecipherable glibc error message on startup (something along the lines of "version `GLIBC blah' not found)

That message happens when a new binary is run on an old glibc, not the other way around.

Yes, you'd think so indeed.

Unfortunately, I've seen the exact opposite in production: older binary running atop newer glibc and crashing with that kind of message.

glibc abi compatibility is and has been a joke.

Another thing is NodeJS. Ever tried using nvm to install a specific nodejs version (lts/carbon for example) in an Alpine CI image? It won't work and worse, it doesn't even show what doesn't work - the error message will simply be "node: file not found".

That this message implies that not the node binary was not found but libc.so is missing, is just mind boggling. Furthermore, installing libc-compat doesn't help, you will actually have to set NVM to download nodejs from the "unofficial-builds" repository. What a load of bollocks.

The reason for the funny message is that it’s not that it’s failing to find libc.so while doing dynamic linking; it’s the kernel failing to find the interpreter designated in the ELF image (ld-linux.so). Unfortunately the kernel responds with an ENOENT, which is indistinguishable to the caller from not finding the binary itself.

C, POSIX is a defined API though, the issue is glibc and the use of internal symbols or glibc specific api's in programs and for some reason things like rawmemchr.

The Microsoft client was probably moved to an all C# solution, which skips over this problem.

Reply on news.ycombinator.com