Linux API由Linux内核的系统调用接口、GNU C库（GNU）、libdrm、libalsa和libevdev组成。Glibc是Linux内核系统调用的封装器。Linux内核和GNU C库共同构成了Linux API。编译后，二进制文件提供ABI。
GNU C库，又名glibc，是GNU计划所实现的C标准库。尽管其名字中带有“C库”，但它现在也直接支持C++（以及间接支持其他编程语言）。它是自由软件基金会（FSF）在20世纪90年代初为他们的GNU操作系统设计的。它为GNU系统，GNU/Linux系统和一些其他的类Unix系统提供了系统核心库。这些库提供了关键的API，包括ISO C11、POSIX.1-2008和BSD所规定的API和一些底层API，包括open、read、write、malloc、printf、getaddrinfo、dlopen、pthread_create、crypt、login、exit等。
^GNU's Bulletin， vol. 1 no. 4， February， 1988. [2020-10-24]. （原始内容存档于2016-04-16）. Most libraries are done. Roland McGrath […] has a nearly complete set of ANSI C library functions. We hope they will be ready some time this spring.
^GNU's Bulletin， vol. 1 no. 12. [2020-10-24]. （原始内容存档于2016-03-11）. It now contains all of the ANSI C-1989 and POSIX.1-1990 functions， and work is in progress on POSIX.2 and Unix functions (BSD and System V)
^Corbet, Jonathan. A turning point for GNU libc. LWN.net. 2012-03-28 [2013-02-05]. （原始内容存档于2016-04-23）. Of the nearly 19，000 commits found in the project's git repository (which contains changes back to 1995)， over 12，000 were made by Ulrich.
^Forking: it could even happen to you. 2008-09-12 [2020-10-24]. （原始内容存档于2009-09-15）. the split between GNU LIBC and the Linux LIBC -- it went on for years while Linux stabilized， and then the forks re-merged into one project
^glibc homepage. [2020-10-24]. （原始内容存档于2016-04-22）. In 2001 The GNU C Library Steering Committee …， was formed and currently consists of Mark Brown， Paul Eggert， Andreas Jaeger， Jakub Jelinek， Roland McGrath and Andreas Schwab.
^Drepper, Ulrich. RMS is at it again. sourceware.org. 2000-06-26 [2015-11-20]. （原始内容存档于2012-12-28）. A few weeks ago RMS started the next attack on me (a single mail， followed by indirect tries to take influence， followed by another mail today). The essence is that he complains I am not following "GNU policies" and therefore have to be replaced by a steering committee of which I could be a part. Some of you (namely Roland and Andreas S.) probably know about this since he proposed both as other members of the committee. In addition there was Mark Brown listed (I know somebody of this name at IBM who would also fit in this group but I'm not sure whether it is really him.) Anyhow， I completely reject this. It is not helping at all， the opposite is true. First， I am not aware of any essential policies I'm violating. The only ones are that I'm not following orders from RMS which clearly have political intends (which is of course a sacrilege) and possibly that I do not care about Winblowz (if the latter counts at all). None of this will change in any way.
^Drepper, Ulrich. glibc 2.2.4. sourceware.com. 2001-08-15 [2015-11-29]. （原始内容存档于2016-04-09）. And now for some not so nice things. Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC).
^OpenMoko components. [2020-10-24]. （原始内容存档于2016-04-22）. We will use glibc (not uClibC) … The alternatives may save more space and be more optimized， but are more likely to give us integration headaches
