5.2. Why do we use static linking?

(Thanks to Plasmatic for posting the text on which this is mainly based to one of the LFS mailing lists.)

When making (compiling) a program, rather than having to rewrite all the functions for dealing with the kernel, hardware, files, etc. every time you write a new program, all these basic functions are instead kept in libraries. glibc, which you install later, is one of these major libraries, which contains code for all the basic functions programs use, like opening files, printing information on the screen, and getting feedback from the user. When the program is compiled, these libraries of code are linked together with the new program, so that it can use any of the functions that the library has.

However, these libraries can be very large (for example, libc.a can often be around 2.5 MB), so you may not want a separate copy of each library attached to the program. Just imagine if you had a simple command like ls with an extra 2.5 MB attached to it! Instead of making the library an actual part of the program, or statically linked, the library is stored as a separate file, which is loaded only when the program needs it. This is what we call dynamically linked, as the library is loaded and unloaded dynamically, as the program needs it.

So now we have a 1 KB file and a 2.5 MB file, but we still haven't saved any space (except maybe RAM until the library is needed). The real advantage of dynamically linked libraries is that we only need one copy of the library. If ls and rm both use the same library, then we don't need two copies of the library, as they can both get the code from the same file. Even when in memory, the two programs share the same code, rather than loading duplicates into memory. So not only are we saving hard disk space, but also precious RAM.

If dynamic linking saves so much room, then why are we making everything statically linked? Well, that's because when you chroot into your brand new (but very incomplete) LFS environment, these dynamic libraries won't be available because they are somewhere else in your old directory tree (/usr/lib for example) which won't be accessible from within your LFS root ($LFS).

So in order for your new programs to run inside the chroot environment you need to make sure that the libraries are statically linked when you build them, hence the --enable-static-link, --disable-shared, and -static flags used through Chapter 5. Once in Chapter 6, the first thing we do is build the main set of system libraries, glibc. Once this is made we start rebuilding all the programs we just did in Chapter 5, but this time dynamically linked, so that we can take advantage of the space saving opportunities.

And there you have it, that's why you need to use those weird -static flags. If you try building everything without them, you'll see very quickly what happens when you chroot into your newly crippled LFS system.

If you want to know more about Dynamically Linked Libraries, consult a book or website on programming, especially a Linux-related site.