The section on architecture support of dietlibc is too optimistic, IMHO. I stumbled upon quite a few function, esp. floating-point-related functions, that simply aren't implemented on x86_64 while they're available while they're available on x86.
But then one needs to understand the background of how and why dietlibc came to be: its original author used to work for a German company developing digital TV set-top boxes and receivers, based on Linux and technologies like DirectFB, so obviously supporting their requirements and optimizing for size aggressively, even if some functionality is non-conformant, has always been a priority.
Full disclosure: I contributed a few patches to dietlibc.
Musl is a really nice libc, small and correct. The team are nice to work with. In particular if you want to static link something to get a completely standalone executable it is a great choice, you can ship a file with no dependencies. The source code is really easy to read if you want to see how things are implemented.
I don't think Bionic is really suitable for this. It's unlikely to even work for building apps that weren't specifically designed for Bionic, since it's rather deficient in its support for many of the standard functions, and also differs moderately from glibc and other more popular libcs in the extensions it provides. Really Bionic was just created to be the minimal libc needed to run Dalvik (Google's "JVM") and everything else looks like an afterthought. I'd really like to add Bionic to the comparison table, but I haven't found a way to build it outside of building a whole Android development environment, which is a huge headache...
Could you clarify what you mean by "doesn't support aarch32"? I can't find any clear definition of what aarch32 means, but my impression is that it's just a new name for what we call "arm", but possibly implying new instructions available on v8, and the ABI is the regular 32-bit ARM EABI. If so musl supports it just fine.
One of the musl devs is also one of the absolute best StackOverflow posters (as “R..”). Unsurprisingly, he mainly answers low-level C questions; his responses are always thoughtful and well worth reading (if you’re interested in such details).
No, none of these will run on BSD. But the BSDs each ship with a perfectly good, small, BSD licensed libc that supports static linking. Bionic libc for Android was more or less ported form one of the BSD libcs. Basically these projects, especially Musl, are trying to provide the equivalent of a BSD libc for Linux...
Note that this table is written by one of the musl authors; not that there's anything shady about it, but it's a list of what the musl authors think are important, so it's to be expected that musl is trying to check off all the boxes, wheras other libc implementations may have different goals.
Yes. If anyone has suggestions for other comparison points I should add that would be more balanced, I can try to add them (but some things require non-trivial work to measure so it might take me a while to get around to it). Note that the comparison table as it stands it pretty old, but very little has changed since I did it except musl getting slightly bigger and glibc getting a lot bigger (and eglibc merging back into glibc, so it's rather pointless to talk about it as "eglibc" anymore). :-)
Musl is fairly new, and it's linux-specific, for those reasons I think many have not heard of it.
But it is very good. We use big parts of it in emscripten for example, and it works great - nice new and compact code, permissive MIT license, friendly upstream.
Odd that there's no mention of Annex K support under the "Security/hardening comparison" heading. While it's optional to implement, it certainly applies.
I don't think there's much value in adding an Annex K comparison anywhere since none of the compared libcs have Annex K functions; comparison items are only meaningful where they differ. Even if some libcs did have it, though, I'd be hesitant to put it under hardening. My concept of "hardening" is providing additional properties beyond the scope of the specification (usually this means in places where undefined behavior occurs, but it could also be implementation-defined things, such as using an alternate pointer representation that allows as much bounds-checking as C makes possible).
The general feeling among many implementors seems to be that the Annex K functions are very much the wrong way to harden string/memory handling. I don't know of any linux or bsd libc that has adopted them.
I'm interested in learning more about how the various libc's are implemented. Can someone suggest one (or other C code) that I can download and look through? I am trying to find high quality open source C to learn from. Thanks
Because there's no real problem with having a 1.5MB glibc on a server or desktop OS, and glibc is quite a lot more featureful than the alternatives. Many lack locale support, nsswitch, backwards binary compatibility and various minor bits and pieces that breaks existing applications.
The size isn't really an issue for most desktop or server oriented distributions. Perhaps bigger issues for distros are:
- Symbol versioning: If you have a newer glibc installed when you build your packages, they'll refuse to run on older glibc, even if they don't need any of the new version's features. This makes it hard to make packages that support multiple versions of a distribution (e.g. a stable release with an older glibc and an unstable release with a newer one).
- Awkwardness of upgrading: For example Debian usually wants you to restart X and any daemons that use nss when glibc is updated. There are also atomicity issues during upgrade where there's a race window during which execing programs can fail.
On the other hand, distros are invested in a huge set of packages as well as support for third-party (often non-free) software, all of which are presently linked with glibc. I think musl is a lot more interesting right now to new and upcoming distros that are looking for a fresh start with less baggage than as a migration path for the big distros with major user/customer bases, at least in the short term. In the long term, who knows what will happen... :-)
The musl figures may be somewhat outdated since musl is developing rather quickly. With regards to the others, the main thing that's outdated is the size of glibc. It's considerably larger now. :-)
A lot of this page dates back to a few years back when glibc had severe bugs in its maintainer, and the eglibc branch/fork was the better choice. Regardless, given the commonalities of the codebases, it's doubtful that the numbers between glibc and eglibc are going to be much different.
eglibc has slowly been merged upstream for the last 2 years. The next eglibc release (2.19) not only will be the last, but it's recommended to use glibc instead unless there's specific need:
> I have now set up the EGLIBC 2.19 branch. This is the last EGLIBC release branch; unless you are relying on changes in EGLIBC relative to glibc that have not been merged to glibc, you are advised to use glibc 2.19 branch instead of EGLIBC 2.19 branch. If you are relying
on such changes, listed below, you should plan to contribute such features to glibc so you can cease using EGLIBC
I don't see anything to suggest that Arch uses eglibc. The glibc package in the repos is clearly the original glibc (look at the name, package URL, and build config) and there is no other package named "eglibc". Also, a very recent forum post[1] implies eglibc is not the standard.
Wikipedia says[2] that Arch uses eglibc, but their source is the eglibc website home page and I find no such claim on the entire site. I can't find anything about eglibc on the Arch mailing list, either.
Yeah, you're right, I can't find anything saying Arch is using eglibc either. I did get my information on it from that Wikipedia article, I guess I should have checked the citations.
Hmmm. I can see you're frustrated, but it's coming out sounding like you feel entitled to other's free work.
Perhaps if you feel the need you could use the author's benchsuite at http://www.etalabs.net/libc-bench.html to test GNU libc and share the results with everyone.
But then one needs to understand the background of how and why dietlibc came to be: its original author used to work for a German company developing digital TV set-top boxes and receivers, based on Linux and technologies like DirectFB, so obviously supporting their requirements and optimizing for size aggressively, even if some functionality is non-conformant, has always been a priority.
Full disclosure: I contributed a few patches to dietlibc.