Glibc is a nasty piece of software full of nonstandard GNUisms that basically implements a separate standard. I've fought for years against the fact they've got

Glibc is a nasty piece of software full of nonstandard GNUisms that basically implements a separate standard. I've fought for years against the fact they've got functions that are not found in any other libc and have different behaviours depending on macros, often conflicting with POSIX or BSD variants. The fact the project was run for almost 20 years by a guy that managed it in a dictatorial style was a huge reason why so many alternative libc existed (that, and the licensing). Few people here remember about EGLIBC I guess. Glibc is also such a mess that it still does not compile with Clang, after _decades_, due to all the crazy GCC extensions they rely on. An attempt is cyclically started and then promptly aborted when some new crazy nonsense is found. For instance, last time I checked they not only used the completely insane folly that GCC nested functions are, but they also relied on GCC attributes so nasty that LLVM never bothered implemented them (like renaming functions at code generation). Using these extensions are not really necessary, and I've a strong suspicious it was more of an attempt by the GNU authors to prevent distributions to ever consider not using GCC as their main compiler. Also how name resolution is implemented in Glibc means you can't really statically link with it. If you've ever noticed, most "statically linked executables" are not in fact statically linked, but require ld.so just for libc. There are good reasons to disallow statically linking libc, but this is not one of them. Especially since the only stable API on Linux is the kernel interface, so the only way to not have to worry about future Glibc breakage is to either link with Musl or live with the risk.