
Dietlibc – a Libc optimized for small size - kick
http://www.fefe.de/dietlibc/
======
tyingq
A comparison of dietlibc, uclibc, musl, and glibc, by the author of musl:
[http://www.etalabs.net/compare_libcs.html](http://www.etalabs.net/compare_libcs.html)

~~~
alexhutcheson
Another factor to consider is release cadence:

\- musl: 4 releases so far in 2019, 2 in 2018, 3 in 2017[1]

\- uClibc: No releases since 2012[2]

\- uClibc-ng: 2 releases in 2019, 3 in 2018, 6 in 2017[3]

\- dietlibc: only 1 release since 2013[4]

[1] [https://www.musl-libc.org/releases/](https://www.musl-libc.org/releases/)

[2] [https://uclibc.org/](https://uclibc.org/)

[3] [https://downloads.uclibc-ng.org/releases/](https://downloads.uclibc-
ng.org/releases/)

[4] [https://www.fefe.de/dietlibc/](https://www.fefe.de/dietlibc/)

~~~
jackewiehose
> \- dietlibc: only 1 release since 2013[4]

you missed the first entry (20180924).

> Another factor to consider is release cadence

It's questionable that "more releases" == "better". Sometimes software is
(ideally) just done (except for security issues). I use a lot of software that
has no significant changes since decades. Regarding a libc-replacement I
couldn't name a single important thing for the last years.

But of course, no release could also be a bad sign, like beeing abandoned or
that is has just no users (testers).

~~~
jcranmer
> Regarding a libc-replacement I couldn't name a single important thing for
> the last years.

* Supporting new syscalls, such as getrandom(), or extra options on existing syscalls (e.g., socket options).

* Support for libc-components of new hardware versions, such as the register state information that you get on signals.

* Supporting new versions of C, such as C11.

* Improving performance of threading and memory allocation, among other things.

* Updating Unicode tables for locale information.

------
vnglst
I like the proverb on the top of the page:

Person who say it cannot be done should not interrupt person doing it.
--Chinese Proverb

~~~
rdescartes
However, I think it maybe a fake proverb.

[https://www.npr.org/2018/06/12/619140377/after-ivanka-
trump-...](https://www.npr.org/2018/06/12/619140377/after-ivanka-trump-quotes-
chinese-proverb-a-hunt-for-the-proverbial-author)

------
avian
I recently encountered dietlibc while trying to debug a segfault in integrit
[1]. As packaged in Debian, integrit is a static binary using dietlibc. For
some unknown reason I found it completely impossible to get any usable
stacktrace out of it with gdb and the usual tools and after a few days of
frustration I gave up on finding the cause.

[1]
[https://github.com/integrit/integrit](https://github.com/integrit/integrit)

~~~
breadbox
Yes, part of the usual process of making a tiny binary is jettisoning much of
the overhead that debuggers depend on in order to find their way through an
external program. Not just the debugging symbols themselves, but things like
section header tables and maintenance of linked stack frames in the running
code. Dumping all of that saves space, at the expense of making the resulting
binary more and more opaque.

------
rwmj
I used dietlibc as a replacement for glibc in supermin, when making an
initramfs. As background the size of the initramfs is key for boot performance
since qemu takes quite some time (where "some time" means milliseconds) to
load a large initramfs; and the binaries in the initramfs are usually
statically linked. The final size of the init binary was about 1/40th as big
as when using glibc:

[https://github.com/libguestfs/supermin/blob/c97b3917068597a0...](https://github.com/libguestfs/supermin/blob/c97b3917068597a0e68e88d9a905da766ade40da/README#L147)

~~~
pmoriarty
I don't do anything special to my initramfs, and the largest of them that I've
generated over the years is 16 MB in size. For my desktop with a 3 TB drive,
having the initramfs take up half a meg instead won't make any appreciable
difference.

I could see it being very useful on resource constrained microcontrollers or
something, though.

~~~
rwmj
It makes a huge difference when trying to boot an appliance virtual machine in
milliseconds. Paper: [http://git.annexia.org/?p=libguestfs-
talks.git;a=tree;f=2016...](http://git.annexia.org/?p=libguestfs-
talks.git;a=tree;f=2016-eng-talk)

------
trileansoftware
Interesting project.

What is the footprint of this compiled for a MCU, something like a STM32?

~~~
kbumsik
This libc is for Linux, so I guess you can't compile it for a bare-metal
system like STM32.

~~~
alexhutcheson
For microcontrollers the most popular open source option is newlib[1].

[1] [http://sourceware.org/newlib/](http://sourceware.org/newlib/)

~~~
mlyle
Keith Packard maintains an excellent "picolibc" that I have used recently (and
contributed to, a little). It was formerly called newlib-nano, and consists of
newlib with the string functions replaced with cheaper (slower) versions from
avrlibc and various other slimming changes (e.g. reduction of struct reent
stuff, and some locale stuff, by default).

[https://github.com/keith-packard/picolibc](https://github.com/keith-
packard/picolibc)

------
mhd
If I remember correctly, dietlibc was part of a whole bunch of DJB-fanboy
releases by fefe way back when dinosaurs and qmail ruled the earth. Not that
much happening since then, I think he's mostly CCC-ish-blogging these days.

~~~
jlg23
If I remember correctly it grew out of frustration with glibc size which
turned into research into how to make a libc as small as possible. No DJB
involved.

> Not that much happening since then, I think he's mostly CCC-ish-blogging
> these days.

Latest release was last year and the changelog[1] suggests it was a group
effort.

Do I smell a personal dislike for the author?

[1]
[http://www.fefe.de/dietlibc/changes-0.34.txt](http://www.fefe.de/dietlibc/changes-0.34.txt)

~~~
mhd
Neither for the author nor for DJB. I was on the mailing list when dietlibc
and libowfat (the alternative, non-traditional, DJB-inspired core library)
were created. Was an interesting time and I liked the philosophy way more than
e.g. the whole 'suckless' stuff (which is more in the Plan 9 corner).

I don't regard "fanboy" as a derogatory term, by the way.

There was quite a lot of development and thoughts back then, but in recent
years I hadn't heard a lot out of that corner, and in German circles I mostly
saw von Leitner's name mentioned when it came to some digital rights thing
(our various German and EU "privacy" laws).

~~~
jackewiehose
> I don't regard "fanboy" as a derogatory term, by the way.

I do. Whenever I read "fanboy", I assume the author is at least no fan of the
subject (in this case I assume you don't like DJB). Otherwise it would just be
a "fan"... ?

