11 ms·
Comparison of C/Posix standard library implementations for Linux
- yoha 13y agoTo 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
- justincormack 13y agoGlibc and eglibc are merging, it seems there will be no more eglibc releases http://www.eglibc.org/archives/patches/msg01321.html http://www.eglibc.org/archives/patches/msg01321.html The development process in glibc was fixed, rather like the egcs split all over again.
- justincormack 13y agoMusl 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.
- aray 13y agoThis is also (IMO) what bionic is great for. It's also licensed compatibly, whereas the rest aren't.
- justincormack 13y agoBionic is very incomplete though. it is not really worth using outside Android you may as well use Musl.
- aray 13y agoMusl (looks like) doesn't support aarch64 and aarch32, so if you're targeting those it's not even an option.
- dalias 13y agoCould 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.
- dalias 13y agoI 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...
- lelf 13y agoAnd no GNU libc. Idiocy.
- bluefinity 13y agoeglibc is basically the same thing, except better. Ubuntu, Debian, and Arch all use eglibc.
- laumars 13y agoArch uses glibc - though the two projects are currently merging anyway.
- B-Con 13y agoI 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/ https://www.archlinux.org/packages/core/x86_64/glibc/ [1]: https://bbs.archlinux.org/viewtopic.php?177180 https://bbs.archlinux.org/viewtopic.php?177180 [2]: http://en.wikipedia.org/wiki/GNU_C_Library http://en.wikipedia.org/wiki/GNU_C_Library
- bluefinity 13y agoYeah, 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.
- masklinn 13y agoeglibc 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 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.
- _ak 13y agoThe 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.
- zdw 13y agoOut of curiosity, are there similar projects that will run on BSD? Or will any of these?
- justincormack 13y agoNo, 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...
- abaillargeon 13y agoI'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
- justincormack 13y agoMusl is very easy to read, recommend looking at that. It is very easy to find your way around.
- zobzu 13y agothe real question is... anyones using this as their libc on servers/desktops with no issues compared to glibc?
- bronson 13y agoWow, just going by quantity of green, Musl looks excellent. Why have I not heard of it until now?
- aidenn0 13y agoNote 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.
- dalias 13y agoYes. 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). :-)
- azakai 13y agoMusl 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.
- mpg39 13y agoWhy not compare to glibc? Am I missing something?
- masklinn 13y agoglibc 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 http://www.eglibc.org/archives/patches/msg01327.html
- stephencanon 13y agoOne 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).
- profquail 13y agoLink to R..'s C answers/questions: http://stackoverflow.com/search?tab=votes&q=user%3a379897%20[c] http://stackoverflow.com/search?tab=votes&q=user%3a379897%20...
- mcguire 13y agoI'm sorry, did it ever say exactly what the implementations were? Specific versions sometimes matter. Devil's in the details and all that.
- dalias 13y agoThe 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. :-)
- BudVVeezer 13y agoOdd that there's no mention of Annex K support under the "Security/hardening comparison" heading. While it's optional to implement, it certainly applies.
- stephencanon 13y agoThe 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.
- dalias 13y agoI 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).
- csense 13y agoIf 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?
- noselasd 13y agoBecause 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.
- dalias 13y agoThe 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... :-)
- deleted 13y ago[deleted]