4 ms·
The real comparison is: musl does not provide any preprocessor macro to tell you what libc you're using. And it has so many weird quirks that you need to work
by o11c 3y ago
The real comparison is: musl does not provide any preprocessor macro to tell you what libc you're using.
And it has so many weird quirks that you need to work around.
***
Static linking makes linking more painful, especially regarding global constructors (which are often needed for correctness or performance). This is not a musl-specific issue, but a lot of people are interested in both.
Just do your builds on the oldest supported system, and dynamic linking works just fine. You can relative-rpath your non-libc dependencies if they would be a pain to install, though think twice about libstdc++.
***
The major advantage of MUSL is that if you're writing a new OS, it's much easier to port.
- yjftsjthsd-h 3y ago> musl does not provide any preprocessor macro to tell you what libc you're using. > And it has so many weird quirks that you need to work around. I was under the impression that musl stuck closely to the standard, and glibc frequently did its own thing, so 1. it's not musl that's quirky, 2. if you need to detect something, just detect glibc.
- o11c 3y agoThe standard is uselessly incomplete and vague. There are places where MUSL implements a broad set of GLIBC extensions in order to actually be useful. However, it does not indicate that in any way, and sometimes violates the conditions that GLIBC documents. This requires workarounds. There are places where MUSL implements a standard interface in a particular way. If you're lucky, this "just" means giving up on performance if you don't know you're using MUSL. Sometimes MUSL implements its own ABI-incompatible extensions. The time64 transition, for example, is a huge mess regardless, but musl provides no blessed way to figure out what's going on. The only reason it's not an even bigger disaster is that almost nobody uses musl.