From 4d515293b6c5b19038ccde51c85eb9b535315c7e Mon Sep 17 00:00:00 2001 From: Gerard Beekmans Date: Fri, 3 Jan 2003 02:51:46 +0000 Subject: Applied Alex' patch to rewrite the why-static section, plus some changes of my own git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2273 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/creatingstaticdir.xml | 17 +++--- chapter05/whystatic.xml | 116 ++++++++++++++++++++-------------------- 2 files changed, 65 insertions(+), 68 deletions(-) (limited to 'chapter05') diff --git a/chapter05/creatingstaticdir.xml b/chapter05/creatingstaticdir.xml index 9e83b9952..f0b34a542 100644 --- a/chapter05/creatingstaticdir.xml +++ b/chapter05/creatingstaticdir.xml @@ -2,19 +2,14 @@ Creating the $LFS/static directory -As explained in this chapter's introduction, everything we install -from this chapter will be installed under the $LFS/static directory. This way it won't -pollute the LFS partition with a bunch of temporary files. All we need to -do is create this directory so we can start installing. Simply run this -command to create the directory: +All programs compiled in this chapter will be installed under $LFS/static to keep them separate from the +programs compiled in the next chapter. The programs compiled here are only +temporary tools and won't be a part of the final LFS system and by keeping them +in a separate directory, we can later easily throw them away. Create the +required directory by running the following: mkdir $LFS/static -You may want to move the packages you downloaded in Chapter 3 to this -$LFS/static directory, perhaps -create a subdirectory $LFS/static/src to keep them in. - diff --git a/chapter05/whystatic.xml b/chapter05/whystatic.xml index b383455b0..9982252a0 100644 --- a/chapter05/whystatic.xml +++ b/chapter05/whystatic.xml @@ -1,62 +1,64 @@ -Why do we use static linking? +Why 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. +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 form 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. + -- cgit v1.2.3-54-g00ecf