There could be so many more interesting LLVM projects to solve problems with existing platforms!
- LLDE - the LLVM Desktop Environment
- ALLSA - the Advanced LLVM Sound Architecture
Conversation
I wish I could take this as light-heartedly as yousall do, but Google already has its own libc, Bionic, and it's the crappiest of the crap software you can imagine calling itself a libc. They should work on perhaps improving that instead of polluting the space with one more.
4
2
13
I totally agree it's ridiculous, especially when musl already exists and seems like it serves all their stated needs?
3
5
I think they primarily care about Fuchsia support, where they use a fork of musl ported over to Fuchsia and with some added features. I think the chance is pretty low of musl supporting Fuschsia upstream, but they could probably land a fair bit of what they need upstream.
2
The original proposal is x86-64 first, and a subsequent response asks for ARM64 support for Fuchsia, so I don't think the main driver it Fuchsia (and if it were, it wouldn't be signed "The Google LLVM Contributors").
1
I doubt it has anything to do with Android though. I'm not sure why they would want it if not for Fuchsia support. There are a lot of things they use that aren't in musl right now but other than Fuchsia support I think most of it would be welcome there, even if a bit reluctantly.
1
Google has quite a few x86-64 machines, running security-critical software. I'm guessing that's the main driver for this proposal 🙂
2
I have a good idea of what's missing from musl for their needs though, and it doesn't make any sense for them to make a whole new libc if it's only for Linux. Having it in LLVM also implies needing to deal with more portability, including deciding how to approach Windows support.
1
I could see people wanting a libc portable across *BSD, Linux, maybe even Windows, etc. I can't understand why Google would want to deal with maintaining that, so that's why I assumed it was compelled by their current fork of musl in Fuchsia. I'm not understanding the reasoning.
FWIW, while it'll be super cool if Fuchsia (or others) can use this, that's not the motivation.
And the team looked at musl (and others) and none seemed to be the right trade off from an engineering POV. (It's possible they're wrong of course, but they are considering them.)
2
Do you know what issue they have with musl other than it being missing sanitizer support (everything other than Bionic and Fuchsia), their preferred malloc implementation and some minor hardening work elsewhere? I expect most could be done upstream too, just not Fuchsia support.
1
Show replies