== Glibc and the Linux API A while back, I wrote an entry on the overall issue of [[if the C runtime and standard library were a legitimate part of the Unix API ../unix/UnixAPIAndCRuntime]]. This was sparked by Go, which tries to avoid the C library on all platforms, Linux included, and where this helped lead to [[a fun problem https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/]]. Linux is an unusual Unix in this regard. Many Unixes are tightly coupled to their standard C library, whether or not they officially documented it as the API to the system in general the way Solaris does. OpenBSD, FreeBSD, and so on all have a definitive standard C library that is part of their base operating system along side the kernel (and their standard C compiler); the kernel and this library are developed in sync by the same people. Linux doesn't have an officially blessed or co-developed standard C library in this way; instead it theoretically supports multiple ones. You're supposed to be able to build a Linux system with [[musl https://www.musl-libc.org/]] or [[uClibc-ng https://uclibc-ng.org/]] or any of the other options out there. In practice, my understanding is that it's sufficiently hard to replace glibc that no large distribution attempts to do so (although [[Alpine https://alpinelinux.org/]] uses [[musl]] and I've heard of it). A certain amount of software doesn't even build when compiled against non-glibc header files, and past that other libc implementations don't necessarily attempt to be exactly compatible (eg, [[musl's list of differences https://wiki.musl-libc.org/functional-differences-from-glibc.html]], and [[see also https://wiki.musl-libc.org/bugs-found-by-musl.html]]). In addition, alternate libcs generally seem to be aimed at being smaller and simpler than glibc, and as part of that they can leave out significant features like [[nsswitch.conf https://linux.die.net/man/5/nsswitch.conf]]. (As a system administrator I'm biased, but yes I consider nsswitch.conf to be a significant feature. It provides significant sysadmin control over a number of important operations.) Or in short, while Linux officially doesn't have a 'standard C library', in practice no one is attempting to provide a full alternative or replacement to glibc. Glibc is not merely the default choice, it is the only full choice. As a result, whatever API glibc decides to supply for something is the de facto Linux standard. This is especially the case if glibc is putting a wrapper around some new Linux kernel feature. As we saw in [[marcan's article https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/]], there may be undocumented requirements that glibc has reverse engineered but you don't necessarily know. (It's not clear to me how thoroughly the Linux kernel API is documented, but [[the *man-pages* project https://www.kernel.org/doc/man-pages/]] does appear to cover the [[actual system calls http://man7.org/linux/man-pages/man2/syscalls.2.html]].) Also, I believe that there are any number of significant projects that consider glibc to basically be part of the overall Linux API and GNU (libc) extensions to be just as potentially legitimate a standard as anything else. These projects are obviously dependent on glibc (or a feature for feature compatible replacement). In 2014, one such project was systemd, [[per Lennart Poettering's comments https://lists.freedesktop.org/archives/systemd-devel/2014-October/023869.html]], and I suspect that systemd's views have not shifted since. (As a practical matter, things like Firefox are not tested, developed, or officially supported against alternate libcs any more than they're tested with unusual C/C++ compilers. If you decide to use them that way anyway, you get to keep all of the many pieces that you're likely to wind up with.) I have some thoughts on this overall situation, but that's going to have to be another entry since this one is already long and rambling enough.