They are great examples of poorly-designed replacements for existing open source software being pushed into widespread adoption solely because the largest Enterprise distribution of Linux willed it.
And also great examples of software developers lying about their intentions early on to silence criticism of their design and the subsequent ramifications of adopting their solutions.
Multiply that by 100 when comparing Google's influence with Redhat's.
If Google wants to develop their own libc, they can. I'm f they want to make it open source, they can. There's nothing about doing those things that necessitates doing so as part of the LLVM project.
Seems to me that trying to upstream is common courtesy before forking. If there is some reason it needs to be integrated with changes to LLVM itself then you might end up with an LLVM fork similar to WebKit/Blink, is that a better outcome?
The point is that no existing libc is part of the LLVM project; i.e., under that umbrella. What's different about Google wanting their own libc and following what Clang and musl do currently?
The question I have is, is there a legitimate reason for tight integration between a compiler and libc? Perhaps there are very good reasons for them to be designed together. A lot of compilers to this for other languages because it allows them to have special logic around intrinsics for example.
