Good primary sources are the `glibc` documentation, especially the FAQ [1], and the `musl` docs, especially the "differences from glibc" section [2] and the FAQ [3], which is basically a long list of ways that `glibc`/`gnulib` developers have leaned into ever-more-broken/nonstandard behavior. If you dig through the GNU mailing lists (which is where I draw the line for an HN comments), you'll find megabytes of admission that this is in an effort to make "GNU/Linux" (or as I've taken to calling it, GNU "plus" Linux, Linux being merely the kernel...), to quote Fassbender as Steve Jobs: "Closed system! Completely incompatible with anything!"

But the short story is that both NSS (DNS lookup), and `iconv` (locale handling) don't work without `glibc`-specific dynamic linking shit. Ostensibly this is because of things like merely being able to read decades-obsolete multibyte character encodings, and not able to write them, is a bridge too far to support at all, let alone as a default. They've also got a bridge they'd like to sell you (see mailing lists).

It's just 90s Microsoft vendor lock-in: "embrace, extend, extinguish" we used to call it. Stallman was a hero for getting the free software movement rolling in the 80s. But in this business, you either die a hero or live long enough to become the villain, and Bill Gates himself would be proud.

[1] https://sourceware.org/glibc/wiki/FAQ [2] https://wiki.musl-libc.org/functional-differences-from-glibc... [3] https://wiki.musl-libc.org/faq.html

I understand why, technically speaking, glibc doesn't support static linking (and I also think that it's bad design). What I don't understand is how this makes it "incompatible with anything". The glibc-specific APIs, sure, they do - to the extent the apps actually use them (which, judging by the intersection of e.g. Debian and FreeBSD package repos, is not exactly common). But how does denying the ability to link statically promote this goal?