
Comparison of C/Posix standard library implementations for Linux - galapago
http://www.etalabs.net/compare_libcs.html
======
_ak
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.

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

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

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

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

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

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

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

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

~~~
justincormack
Glibc 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.

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

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

[http://stackoverflow.com/search?tab=votes&q=user%3a379897%20...](http://stackoverflow.com/search?tab=votes&q=user%3a379897%20\[c\])

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

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

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

Why have I not heard of it until now?

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

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

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

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

------
mpg39
Why not compare to glibc? Am I missing something?

~~~
masklinn
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](http://www.eglibc.org/archives/patches/msg01327.html)

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

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

------
csense
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?

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

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

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

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

------
lelf
And no GNU libc. Idiocy.

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

~~~
B-Con
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/](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
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.

