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. Under certain circumstances, this executable can have the disadvantage of being somewhat slower than a statically linked one, as the linking at run time takes a few moments. It should be noted, however, that under normal circumstances on today's hardware, a dynamically linked executable will be faster than a statically linked one as the library function being called by the dynamically linked executable has a good chance of already being loaded in your system's RAM.
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 the first two packages in this chapter statically? The reason is to make them independent from the libraries on your host system. The advantage is that, if you are pressed for time, you could skip the second passes over GCC and Binutils, and just use the static versions to compile the rest of this chapter and the first few packages in the next. In the next chapter we will be chrooted to the LFS partition and once inside the chroot environment, the host system's Glibc won't be available, thus the programs from GCC and Binutils will need to be self-contained, i.e. statically linked. However, we strongly advise against skipping the second passes.