GNU libc, the standard C subroutine library for Linux

cLIeNUX uses the Linux version of GNU libc. libc is the standard library of linkable subroutines used by almost all C programs. As such it is the foundation of cLIeNUX user-space, and all other Linux distributions I am aware of. The notable exception is the kernel, which can't use libc because libc is based on kernel calls which "don't exist yet" as far as the kernel is concerned. The kernel, like many other large works, does use the static library mechanism described below in it's build process. GNU libc supports several standards for libc, and can be told which subset to use for linking to a particular program. The base standard is the ANSI C standard, and then the POSIX standard adds some unix-oriented facilities, and then there are features specific to the Berkeley or AT&T families of unices, such as symbolic links. There are probably GNU-specific features lurking in libc as well. The "memfrob" routine seems to me to have that tell-tale GNU ring to it, for example.

I'm writing this page for several reasons. GNU libc.info is too big to include in cLIeNUX Core, but is unspeakably rich in valuable information. This seedoc is to urge you to get the GNU docs, which should be in a cLIeNUX package as html, or from a GNU libc package ( not a Linux one, last time I looked) as texinfo. This seedoc is also an excercise for me as I study libc, and to provide some viewpoints on libc from someone who doesn't particulary like the C programming language, but admires what's been done in it. Also, GNU, somewhat necessarily, tends to present things in what is to my tastes a rather top-down fashion, which is appropriate considering the wide range of platforms GNU gcc and other GNU resources run on. cLIeNUX can be a bit more bottom-up in terms of presentation, and that's my tendency anyway.

Use of libc is not actually specific to the C programming language. Linkable subroutines are machine code, and don't really know any more what high-level language they were written in, if any. By "subroutine", for the purpose at hand, I mean a runnable piece of code that can be run by a command, but can not be called as a command itself. The linking mechanism pre-dates high-level languages, and is an adjunct of the process of producing runnable programs with (or in fact, without) an assembler. On Linux recently, as well as some other unices, a runnable command is a file of informational headers, code, and data in the ELF format, Executable Linkable Format, or the traditional, simpler, less flexible a.out format. The documentation on ELF is also very valuable. Linking to libc is a matter of producing executable machine code for your platform, formatting it into an ELF format file, and observing the parameter-passing needs of the routines to be used from libc or other library, and running the linker. That is, a given subroutine needs certain information, usually, and produces certain information, usually. How that information is conveyed between your program and the subroutine is the parameter passing.

An installed C library consists of two main parts. The library itself is the main thing. It may exist as either/or a static or shared library. A static library is simpler. It is an archive file of linkable files. An archive is a compound file, in a sense. It is a file containing other files in thier entirety, and an index to the contained files. libc.a is created from the many files of compiled code of libc with the ar archiving utility. GNU ld knows about GNU ar and ar archives, and can link to any routine in an ar archive if given the name of the archive, rather than linking to each routine or component file specifically. The ar mechanism and the .a suffix are used for libraries to be statically linked. When you make a standalone command from libc.a and your code, it is said to be "statically" linked, which doesn't make sense until we see what "dynamic" linking is.

A similar but more complex structure than an ar archive is what is known as an ELF "sharable object". libc.so.[version#] is an .so . This is an archive with additional information that allows runnable commands to be built without actually including the linked-in subroutine code in the executable file. The linux kernel and the ELF format allow "dynamic" linking. A dynamically linked command does not itself run when called at the command line. What runs first when a dynamically linked executable is invoked is the dynamic linker, which is ld.so-linux for ELF files. The dynamic linker then links the program to libc, which is probably already in memory, and runs it. Dynamic linking is the norm in Linux user space, because it saves a lot of code redundancy in a large system. Only libc.so itself need exist for all programs that use it. There are various trade-offs between static and dynamic.

The other major component of an installed libc, after the library itself, is the header files. Header files are C code that defines routines and data in the library. This is where the parameter passing for each routine is defined. Header files are sometimes made part and parcel of formal software standards, such as for the X Window System. Header files are intended to be used with the C preprocessor #include mechanism so that code in different files can share information about certain routines by simply including the header file in question. In the case of libc, if your code includes the pertinent libc C header files, your program will be built with the same definitions for things in libc as the library itself was built with, and communication between your C program and the library routines is quite automated and defined rather nicely.

There you have the minimal rudiments of libc. More information is available in the cLIeNUX documentation packages, which include seedocs generated from the standard section 3 manpages for libc calls, and in the header files, and in the library itself via nm, objdump and other GNU binutils.

RIGHTS

Copyright 1999 Richard Allen Hohensee
This file is released for redistribution only as part of an entire intact cLIeNUX Core.