1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
<sect1 id="ch05-whystatic">
<title>Why do we use static linking?</title>
<?dbhtml filename="whystatic.html" dir="chapter05"?>
<para>(Thanks to Plasmatic for posting the text on which this is mainly
based to one of the LFS mailing lists.)</para>
<para>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.</para>
<para>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.</para>
<para>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
<emphasis>real</emphasis> advantage of
dynamically linked libraries is that we only need one copy of the library.
If <filename>ls</filename> and <filename>rm</filename> 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.</para>
<para>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
(<filename>/usr/lib</filename> for example) which won't be accessible
from within your LFS root (<filename>$LFS</filename>).</para>
<para>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 <userinput>--enable-static-link</userinput>,
<userinput>--disable-shared</userinput>, and
<userinput>-static</userinput> 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.</para>
<para>And there you have it, that's why you need to use those weird
<userinput>-static</userinput> flags. If you try building everything
without them, you'll see very quickly what
happens when you chroot into your newly crippled LFS system.</para>
<para>If you want to know more about Dynamically Linked Libraries, consult a
book or website on programming, especially a Linux-related site.</para>
</sect1>
|
