diff options
Diffstat (limited to 'chapter05/whystatic.xml')
| -rw-r--r-- | chapter05/whystatic.xml | 61 |
1 files changed, 0 insertions, 61 deletions
diff --git a/chapter05/whystatic.xml b/chapter05/whystatic.xml deleted file mode 100644 index 1b07b0b2e..000000000 --- a/chapter05/whystatic.xml +++ /dev/null @@ -1,61 +0,0 @@ -<sect1 id="ch05-whystatic"> -<title>Why we use static linking</title> -<?dbhtml filename="whystatic.html" dir="chapter05"?> - -<para>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 -<filename>glibc</filename>. To get an idea of what it contains, have a look at -<filename>glibc/index.html</filename> somewhere on your host system.</para> - -<para>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.</para> - -<para>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.</para> - -<para>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.</para> - -<para>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.</para> - -<para>In summary we can say that dynamic linking trades run time against -memory space, disk space, and recompile time.</para> - -<para>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 <emphasis>against</emphasis> skipping the second passes.</para> - -</sect1> - |