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/

[2] https://uclibc.org/

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

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

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

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

I don't think openbsd libc has ever kept the same version for two consecutive releases (six months). Which doesn't even count bug fixes as a version change. There's always something to add or remove.

musl has 4 for 2019.

musl-1.1.24.tar.gz (sig) - October 13, 2019

musl-1.1.23.tar.gz (sig) - July 16, 2019

musl-1.1.22.tar.gz (sig) - April 9, 2019

musl-1.1.21.tar.gz (sig) - January 21, 2019

http://www.musl-libc.org/oldversions.html

Good note - I missed those because the format of the text was different on the page I linked to. Fixed!

is libc something that generally requires multiple releases every year?

Given the chip architectural changes in the last 6 years, I'd hope to see at least more than one release in that time frame.

Often (not allways, naturally) it's enough to just rebuild with a newer compiler to leverage the new arch features.

Out of interest, what are some new things (those bringing real performance gain) from the last 6 years which a standard library needs to adapt to actively?

Edit: also note that OP made this pointed on purpose, the last release is from 2018, one year ago, not 2013...

The standard library benefits a great deal from ASM optimized implementations of functions. New instructions get added that can speed things up significantly.

the compiler will almost never automatically generate this code.

This is all true, but I’m not sure the authors of these libraries are that interested in performance.

It needs to keep up with underlying changes in the operating system from time to time.

Should note that glibc now supports c11 threads. AFAIK there was some problem with their initial specification that caused them to want not to implement them, and c18 amended that so they're now comfortable supporting them.

Also note that openrisc has been mostly superceded by risc-v, which afaik glibc and musl both support; don't know about the other libcs.

These are rather old though:

  musl 1.1.5
  uClibc 0.9.33.2 (Buildroot 2015.02)
  dietlibc 0.32
  glibc 2.19

musl is at 1.1.24 at the time of writing.

Came here for this- musl is a very nice libc and I don’t find the comparison too biased personally.

Is there a reason none of these replacement libcs are available for Windows?

Because part of what libc does is bridge the OS and user space. This is very much OS dependent. You can get a rough idea by looking at where it makes "syscalls."

That's not true for the vast majority of libc. It's usually file IO, memory mapping and command line IO that use system calls and everything else builds on those or just modifies memory.

Threading as well. It means porting requires significant work.

How so? I've dug into the source of musl and allocators like jemalloc. Windows has VirtualAlloc as its analog to mmap and a simple function to print to the command line. Starting threads is similar. Most of libc is pure C. Even most of musl is optimizations for different platforms and compilers. The simple straightforward versions of functions are not anywhere near the complexity of what gets used most of the time.

Most libcs aren't cross-platform; there is mingw, which provides an alternate libc on windows. I'm not actually sure why the libcs aren't cross-platform; I'm currently working on one which plans to support freebsd, linux, and windows.

Well.... there's WCRT: http://www.ibsensoftware.com/files/WCRT-1.16.104.zip