4 ms·

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 doe

by moomin 7y ago

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

tyingq 7y ago
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.
ur-whale 7y ago
This actually goes further than that as different version of glibc aren't ABI compatible with one another.
- bonzini 7y ago
  They are backwards-compatible (which is all you can do of course).
  - ur-whale 7y ago
    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)
    - floatboth 7y ago
      That message happens when a new binary is run on an old glibc, not the other way around.
      - ur-whale 7y ago
        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.
unlinked_dll 7y ago
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.
mschuster91 7y ago
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.
- johncolanduoni 7y ago
  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.
runfaster2000 7y ago
The Microsoft client was probably moved to an all C# solution, which skips over this problem.
nwmcsween 7y ago
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.

by moomin 7y ago

tyingq 7y ago

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.

ur-whale 7y ago

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

bonzini 7y ago
They are backwards-compatible (which is all you can do of course).
- ur-whale 7y ago
  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)
  - floatboth 7y ago
    That message happens when a new binary is run on an old glibc, not the other way around.
    - ur-whale 7y ago
      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.

unlinked_dll 7y ago

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.

mschuster91 7y ago

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.

johncolanduoni 7y ago
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.

runfaster2000 7y ago

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

nwmcsween 7y ago

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.