Fair enough. I agree coding absolute paths inside a libc is a bad design. Frankly, the more I see of the gnu toolchain et al, esp glibc, the less I like. If this was a minor language, I'd say it wasn't fit for real-world use (;-). In practice, it's just showing its age. Thank you for writing musl, and shining a light into some of the horrors.
I've hit another roadblock with PAM - innetgr is not defined. It seems there's a configure check for it, which is then not consistently used. Any ideas for a dirty workaround - even if it means some pam modules aren't useful? What would a dummy stub do?
PS I'm using musl to compile my own distro set up to get a handle on why the traditionally gnu-based c-compiled world of Linux programs, esp when cross-compiled, is so brittle and bug-prone... Everything I've seen so far, including the GNU toolchain, autoconf, m4, make, libtool (uggh) and its ilk has only confirmed my prejudices - too much ego and high theory, not enough real-world pragmatism. Indeed, most of it seems to be more about copying what was already done without really understanding why it was done the way it was, rather than innovating...