Most programs have to perform, beside their specific task, many rather common and trivial operations, such as allocating memory, searching directories, opening and closing files, reading and writing them, string handling, pattern matching, arithmetic, and so on. Instead of obliging each program to reinvent the wheel, the GNU system provides all these basic functions ready-made in libraries. The major library on any Linux system is glibc. To get an idea of what it contains, have a look at glibc/index.html somewhere on your host system.
There are two ways of linking the functions from a library to a program that uses them: statically or dynamically. When a program is linked statically, the code of the used functions is included in the executable, resulting in a rather bulky program. When a program is dynamically linked, what is included is a reference to the linker, the name of the library, and the name of the function, resulting in a much smaller executable. This executable has the disadvantage of being somewhat slower than a statically linked one, as the linking at run time takes a few moments.
Aside from this small drawback, dynamic linking has two major advantages over static linking. First, you need only one copy of the executable library code on your hard disk, instead of having many copies of the same code included into a whole bunch of programs -- thus saving disk space. Second, when several programs use the same library function at the same time, only one copy of the function's code is required in core -- thus saving memory space.
Nowadays saving a few megabytes of space may not seem like much, but many moons ago, when disks were measured in megabytes and core in kilobytes, such savings were essential. It meant being able to keep several programs in core at the same time and to contain an entire Unix system on just a few disk volumes.
A third but minor advantage of dynamic linking is that when a library function gets a bug fixed, or is otherwise improved, you only need to recompile this one library, instead of having to recompile all the programs that make use of the improved function.
In summary we can say that dynamic linking trades run time against memory space, disk space, and recompile time.
But if dynamic linking saves so much space, why then are we linking all programs in this chapter statically? The reason is that we won't be compiling a temporary glibc here. And we avoid doing this simply to save some time -- around 14 SBUs. Another reason is that the Glibc version on the LFS system might not be compatible with the Glibc on the host system. Applications compiled against your host system's Glibc version may not run properly (or at all) on the LFS system.
This means that the tools compiled in this chapter will have to be self-contained, because when later on we chroot to the LFS partition the GNU library won't be available. That is why we use the -static, --enable-static-link, and --disable-shared flags throughout this chapter, to ensure that all executables are statically linked. When we come to the next chapter, almost the first thing we do is build glibc, the main set of system libraries. Once this is done, we can link all other programs dynamically (including the ones installed statically in this chapter) and take advantage of the space saving opportunities.