1 | <sect1 id="ch05-whystatic">
|
---|
2 | <title>Why do we use static linking?</title>
|
---|
3 | <?dbhtml filename="whystatic.html" dir="chapter05"?>
|
---|
4 |
|
---|
5 | <para>Thanks to Plasmatic for posting the text on which this is mainly
|
---|
6 | based to one of the LFS mailing lists.</para>
|
---|
7 |
|
---|
8 | <para>When making (compiling) a program, rather than having to rewrite all the
|
---|
9 | functions for dealing with the kernel, hardware, files, etc. every time you
|
---|
10 | write a new program, all these basic functions are instead kept in libraries.
|
---|
11 | glibc, which you install later, is one of these major libraries, which contain
|
---|
12 | code for all the basic functions programs use, like opening files, printing
|
---|
13 | information on the screen, and getting feedback from the user. When the
|
---|
14 | program is compiled, these libraries of code are linked together with the new
|
---|
15 | program, so that it can use any of the functions that the library
|
---|
16 | has.</para>
|
---|
17 |
|
---|
18 | <para>However, these libraries can be very large (for example, libc.a
|
---|
19 | from can often be around 2.5MB), so you may not want a separate copy of
|
---|
20 | each library attached to the
|
---|
21 | program. Just imagine if you had a simple command like ls with an extra 2.5MB
|
---|
22 | attached to it! Instead of making the library an actual part of the
|
---|
23 | program, or Statically Linked, the library is kept a separate file,
|
---|
24 | which is loaded only when the program needs it. This is what we call Dynamically
|
---|
25 | Linked, as the library is loaded and unloaded dynamically, as the program needs
|
---|
26 | it.</para>
|
---|
27 |
|
---|
28 | <para>So now we have a 1kb file and a 2.5MB file, but we still haven't saved any
|
---|
29 | space (except maybe RAM until the library is needed). The REAL advantage to
|
---|
30 | dynamically linked libraries is that we only need one copy of the library.
|
---|
31 | If <filename>ls</filename> and <filename>rm</filename> both use the same
|
---|
32 | library, then we don't need two copies of the
|
---|
33 | library, as they can both get the code from the same file.
|
---|
34 | Even when in memory, both programs share the same code, rather than loading
|
---|
35 | duplicates into memory. So not only are we saving hard disk space, but also
|
---|
36 | precious RAM.</para>
|
---|
37 |
|
---|
38 | <para>If dynamic linking saves so much room, then why are we making everything
|
---|
39 | statically linked? Well, that's because when you chroot into your brand new
|
---|
40 | (but very incomplete) LFS environment, these dynamic libraries won't be
|
---|
41 | available because they are somewhere else in your old directory tree
|
---|
42 | (<filename>/usr/lib</filename> for example) which won't be accessible
|
---|
43 | from within your LFS root (<filename>$LFS</filename>).</para>
|
---|
44 |
|
---|
45 | <para>So in order for your new programs to run inside the chroot environment you
|
---|
46 | need to make sure that the libraries are statically linked when you build
|
---|
47 | them, hence the <userinput>--enable-static-link</userinput>,
|
---|
48 | <userinput>--disable-shared</userinput>, and
|
---|
49 | <userinput>-static</userinput> flags used
|
---|
50 | through Chapter 5. Once in Chapter 6, the first thing we do is build the
|
---|
51 | main set of system libraries, glibc. Once this is made we start rebuilding
|
---|
52 | all the programs we just did in Chapter 5, but this time dynamically linked,
|
---|
53 | so that we can take advantage of the space saving opportunities.</para>
|
---|
54 |
|
---|
55 | <para>And there you have it, that's why you need to use those weird
|
---|
56 | <userinput>-static</userinput> flags. If you try building everything
|
---|
57 | without them, you'll see very quickly what
|
---|
58 | happens when you chroot into your newly crippled LFS system.</para>
|
---|
59 |
|
---|
60 | <para>If you want to know more about Dynamically Linked Libraries, consult a
|
---|
61 | book or website on programming, especially a Linux-related site.</para>
|
---|
62 |
|
---|
63 | </sect1>
|
---|