I don't think Lennart changed his opinion, if you look further in this thread[1] Lenart wasn't ever against musl per se, it is more like "we use non-POSIX features from glibc that we found useful, and we are not going to reinvent them, so either convince musl to implement those features or carry patches fixing the issues". That I kind concur with him, instead of workaround missing functions it may be better to just write a compatibility library that complements musl with the missing functions. This way, any program that needs those functions could just import this library if they're compiling in a non-glibc system.
I am seeing that lots of the fixes proposed by the author are things like "missing import because glibc exposes some symbols by mistake and musl does not". And this is definitely the kind of fix that upstream would accept[2].
> This library is designed to be used for binaries that are already compiled
against glibc. It does not contain any headers, and cannot be used to build
software that requires glibc. It is instead recommended that any software that
requires glibc APIs be modified to become more portable.
This is exactly the opposite that I was talking about. What I was talking is a library that expose glibc compatible headers to compile software that uses Glibc-isms with minor or zero modifications, but this instead is a compatibility layer for binaries and doesn't expose headers (probably for proprietary software that can't be recompiled).
