> I feel like the problem most people run into today is glibc vs. musl differences. They develop on Ubuntu, then think they can just copy their binaries into a "FROM alpine:latest" container, which doesn't actually work.
Could it work with gcompat? Alpine has it in the community repo.
Re:Win32 Is the Only Stable ABI on Linux?
by naniwaduni on Monday August 15, 2022 @05:47PM
(#32475847)
gcompat is roughly the "yeah the plugs look the same so just stick the 120 V device into the 240 V socket" approach to libc compatibility.
that's running it directly on musl. gcompat is more like a passive adapter which works except you need to know if the device you're plugging in actually supports 240V, which most stuff does nowadays but when it doesn't it explodes horribly.
Re:Win32 Is the Only Stable ABI on Linux?
by flohofwoe on Tuesday August 16, 2022 @03:18AM
(#32480092)
Static linking against MUSL only makes sense for relatively simple command line tools. As soon as 'system DLLs' like X11 or GL are involved it's back to 'DLLs all the way down'.
Re:Win32 Is the Only Stable ABI on Linux?
by matheusmoreira on Tuesday August 16, 2022 @02:38AM
(#32479837)
> Was static linking not enough?
It is a GPL violation when non-GPL software does it.
Re:Win32 Is the Only Stable ABI on Linux?
by seba_dos1 on Monday August 22, 2022 @12:38AM
(#32547411)
glibc is LGPL, not GPL, so it wouldn't be a violation as long as you provided its source code and ability to replace it by the user, for example by providing compiled object files for relinking. And musl is MIT, so no problems there either.
I feel like the problem most people run into today is glibc vs. musl differences. They develop on Ubuntu, then think they can just copy their binaries into a "FROM alpine:latest" container, which doesn't actually work.
It is possible, though, that whatever you statically link doesn't work with the running kernel, of course. And there are a lot of variants out there; every distribution has their own patch cadence. (A past example of this was the Go memory corruption issue from 1.13 on certain kernels. 1.14 added various checks for distribution + kernel version to warn people of the issue, and still got it wrong in several cases. Live on the bleeding edge, die on the bleeding edge.)