Glibc and the Linux API

January 10, 2018

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. 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. 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 or uClibc-ng 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 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, and see also). 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.

(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, 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 does appear to cover the actual system calls.)

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

Written on 10 January 2018.
« Differences between keywords and constants in Python
Linux's glibc monoculture is not a bad thing »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 10 02:57:56 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.