There is also my own 'minifs' https://github.com/buserror/minifs ; it's targeted at embedded, but it works fine on x86s too. Haven't ported it to musl yet (mostly due to the fact that musl wasn't yet merged into crosstool-NG) but that's high on my list.
One thing minifs does is that it has a 'cross linker' took that jettisons every piece of code/library that is not actively linked by executable; also, instead of installing everyone's crap everywhere, I build the distro the other way around, and 'pick and chose' the bits that packages need until they work.
There's also Void Linux, which has musl and glibc versions of packages and offers both musl-based and glibc-based download images: http://www.voidlinux.eu/
This isn't perfect, but kinda works (even with autoconf). I also tried to add musl support into LLVM/clang, but I've been too busy recently, and won't be able to work on it for a while.
A side note: Clang is such a beauty whose structure is so easy to understand yet very extendible. There are actually few things to be done on clang to support musl. Just implement a proper frontend, and you're mostly done. But it's kinda difficult to patch codes which assume glibc, and the fact that musl refuses to export __MUSL__ macro makes the job even harder.
Excuse the noob question, but why are there different libc implementations at all? I mean, their featureset is defined by standard, so all implementations should strive for the maximum performance - so where comes the bloat from?
Support for multiple archs is of course a valid source for percieved bloat, but that should matter only at compile time?
I think you'd be surprised at how much variation there is in the feature set. libc isn't just the C standard library as defined by the language standard. It's the OS standard library too, and includes POSIX stuff and some de facto standard stuff and some OS-specific stuff. The musl author has a comparison table: http://www.etalabs.net/compare_libcs.html
Historically, the biggest reasons for alternate libcs have been to make tradeoffs for use on embedded systems (uClibc) or political/license differences.
One use case is embedded systems. The code space available can vary from a few kilobytes to a few mbs as well as memory overhead. Sometimes you won't even pull an entire library with even though it's small, you'll statically link in only the functions you used.
You will after a bit run into issues using Musl with a wrapper script, in my experience, and you are better off using a Musl based distro. You can run one in a chroot, I used to use Sabotage like that quite a bit, or if you use Docker you can just use "FROM alpine" and everything will be nice and statically linked, or you can do an install in a VM.
musl is great, but it would great if there was something at the compiler level that is better than both gcc and LLVM/Clang.
LLVM/Clang is a step in the right direction but it's quite bloated because of support for C++, Objective-C etc (for C standards at least); not to mention it's written in C++.
Being a Python/C hybrid enthusiast, I looked into taking something like Eli Bendersky's pycparser and making it featureful (preprocesser parsing at the minimum), but haven't done anything in that direction. Maybe some way of combining pycparser and tcc.
What's wrong with being written in C++? It's a high-level, fast language with higher-level abstractions and better typesafety than C and decades of expertise built up around it.
Sure, that means it has some legacy bits that need to be supported, but to some degree that's the price of having a mature codebase.
Having compiled LLVM and rooted through its internals trying to implement a plugin, it looks pretty well-architected and internally consistent. Codebases that cover as much as LLVM+Clang do being that clean is a rare sight, IMO. And it's not slow.
There is pcc which looked like it had a chance for a while. There was at least a lot of excitement from the OpenBSD and NetBSD communities a while ago. I know it was imported but then I think it was removed. Development continues on but at a slower pace.
[+] [-] vezzy-fnord|10 years ago|reply
[+] [-] raphaelss|10 years ago|reply
[+] [-] buserror|10 years ago|reply
One thing minifs does is that it has a 'cross linker' took that jettisons every piece of code/library that is not actively linked by executable; also, instead of installing everyone's crap everywhere, I build the distro the other way around, and 'pick and chose' the bits that packages need until they work.
[+] [-] andolanra|10 years ago|reply
[+] [-] esjeon|10 years ago|reply
This isn't perfect, but kinda works (even with autoconf). I also tried to add musl support into LLVM/clang, but I've been too busy recently, and won't be able to work on it for a while.
A side note: Clang is such a beauty whose structure is so easy to understand yet very extendible. There are actually few things to be done on clang to support musl. Just implement a proper frontend, and you're mostly done. But it's kinda difficult to patch codes which assume glibc, and the fact that musl refuses to export __MUSL__ macro makes the job even harder.
[+] [-] mschuster91|10 years ago|reply
Support for multiple archs is of course a valid source for percieved bloat, but that should matter only at compile time?
[+] [-] wtallis|10 years ago|reply
Historically, the biggest reasons for alternate libcs have been to make tradeoffs for use on embedded systems (uClibc) or political/license differences.
[+] [-] vezzy-fnord|10 years ago|reply
All the bugs discovered by musl, and how many are glibc-related: http://wiki.musl-libc.org/wiki/Bugs_found_by_musl
If you want to know why someone would want to replace glibc, then I give you a challenge: figure out how glibc implements printf(3). Good luck.
The answer is: http://blog.hostilefork.com/where-printf-rubber-meets-road/
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] laichzeit0|10 years ago|reply
[+] [-] gct|10 years ago|reply
[+] [-] IshKebab|10 years ago|reply
[+] [-] stefanmielke|10 years ago|reply
Edit: Using an iPad 2.
[+] [-] aninteger|10 years ago|reply
[+] [-] ksherlock|10 years ago|reply
[+] [-] justincormack|10 years ago|reply
[+] [-] fizixer|10 years ago|reply
LLVM/Clang is a step in the right direction but it's quite bloated because of support for C++, Objective-C etc (for C standards at least); not to mention it's written in C++.
Being a Python/C hybrid enthusiast, I looked into taking something like Eli Bendersky's pycparser and making it featureful (preprocesser parsing at the minimum), but haven't done anything in that direction. Maybe some way of combining pycparser and tcc.
[+] [-] koko775|10 years ago|reply
Sure, that means it has some legacy bits that need to be supported, but to some degree that's the price of having a mature codebase.
Having compiled LLVM and rooted through its internals trying to implement a plugin, it looks pretty well-architected and internally consistent. Codebases that cover as much as LLVM+Clang do being that clean is a rare sight, IMO. And it's not slow.
[+] [-] aninteger|10 years ago|reply
[+] [-] ksherlock|10 years ago|reply
[+] [-] GFK_of_xmaspast|10 years ago|reply
[+] [-] sriku|10 years ago|reply