Comparison of C/Posix standard library implementations for Linux | Hacker News Reader

Comparison of C/Posix standard library implementations for Linux

etalabs.net

110 pointsgalapago40 comments

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.

Also the ARMv8 (aarch32 and aarch64) seem to be missing.

Well, it supports S390 and IA64. That shows you in which decade much of its development happened.

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.

This is also (IMO) what bionic is great for. It's also licensed compatibly, whereas the rest aren't.

Bionic is very incomplete though. it is not really worth using outside Android you may as well use Musl.

Musl (looks like) doesn't support aarch64 and aarch32, so if you're targeting those it's not even an option.

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.

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...

To make it clearer: the article compares several implementations of libc for systems.

On a desktop, the most common one is eglibc. uClibc is the implementation you will find on µClinux, a common version of Linux for embedded systems.

Note: historically, eglibc is a variant of glibc for embedded systems (Embedded GNU libc) but finally replaced it

Glibc and eglibc are merging, it seems there will be no more eglibc releases

http://www.eglibc.org/archives/patches/msg01321.html

The development process in glibc was fixed, rather like the egcs split all over again.

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).

Link to R..'s C answers/questions:

http://stackoverflow.com/search?tab=votes&q=user%3a379897%20...

Out of curiosity, are there similar projects that will run on BSD? Or will any of these?

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...

Wow, just going by quantity of green, Musl looks excellent.

Why have I not heard of it until now?

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.

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 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).

Why not compare to glibc? Am I missing something?

glibc and eglibc are more or less merged[0], probably oversight from when eglibc was simply a better glibc

[0] http://www.eglibc.org/archives/patches/msg01327.html

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

Musl is very easy to read, recommend looking at that. It is very easy to find your way around.

If I was a Linux distributor, I would seriously consider replacing 1.5 MB glibc with an alternative (musl based on this chart).

Why aren't more distros looking at the possibility?

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... :-)

I'm sorry, did it ever say exactly what the implementations were? Specific versions sometimes matter. Devil's in the details and all that.

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. :-)

the real question is... anyones using this as their libc on servers/desktops with no issues compared to glibc?

And no GNU libc. Idiocy.

eglibc is basically the same thing, except better. Ubuntu, Debian, and Arch all use eglibc.

Arch uses glibc - though the two projects are currently merging anyway.

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.

Have I missed something?

[0]: https://www.archlinux.org/packages/core/x86_64/glibc/

[1]: https://bbs.archlinux.org/viewtopic.php?177180

[2]: http://en.wikipedia.org/wiki/GNU_C_Library

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.

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

http://www.eglibc.org/archives/patches/msg01327.html

Although versions are unspecified, for all intents and purposes testing eglibc was either identical to or better than testing glibc.

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.

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.

Reply on news.ycombinator.com