Added a few comments here and there
[linux_from_scratch.git] / newxml / chapter05 / toolchaintechnotes.xml
blob4e3b6a1a57cd4082d76fb07b07c30f7dd1eb59c5
1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3CR2//EN" "http://www.docbook.org/xml/4.3CR2/docbookx.dtd">
3 <sect1 id="ch05-toolchaintechnotes">
4 <title>Toolchain technical notes</title>
5 <?dbhtml filename="toolchaintechnotes.html"?>
7 <para>This section attempts to explain some of the rationale and technical
8 details behind the overall build method. It's not essential that you understand
9 everything here immediately. Most of it will make sense once you have performed
10 an actual build. Feel free to refer back here at any time.</para>
12 <para>The overall goal of <xref linkend="chapter05"/> is to provide a sane,
13 temporary environment that we can chroot into, and from which we can produce a
14 clean, trouble-free build of the target LFS system in
15 <xref linkend="chapter06"/>. Along the way, we attempt to divorce ourselves
16 from the host system as much as possible, and in so doing build a
17 self-contained and self-hosted toolchain. It should be noted that the
18 build process has been designed in such a way so as to minimize the risks for
19 new readers and provide maximum educational value at the same time. In other
20 words, more advanced techniques could be used to build the system.</para>
22 <important>
23 <para>Before continuing, you really should be aware of the name of your working
24 platform, often also referred to as the <emphasis>target triplet</emphasis>. For
25 many folks the target triplet will be, for example:
26 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
27 triplet is to run the <filename>config.guess</filename> script that comes with
28 the source for many packages. Unpack the Binutils sources and run the script:
29 <userinput>./config.guess</userinput> and note the output.</para>
31 <para>You'll also need to be aware of the name of your platform's
32 <emphasis>dynamic linker</emphasis>, often also referred to as the
33 <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
34 <emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided
35 by Glibc and has the job of finding and loading the shared libraries needed by a
36 program, preparing the program to run and then running it. For most folks, the
37 name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On
38 platforms that are less prevalent, the name might be
39 <emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have
40 something completely different. You should be able to determine the name
41 of your platform's dynamic linker by looking in the
42 <filename class="directory">/lib</filename> directory on your host system. A
43 surefire way is to inspect a random binary from your host system by running:
44 <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>
45 and noting the output. The authoritative reference covering all platforms is in
46 the <filename>shlib-versions</filename> file in the root of the Glibc source
47 tree.</para>
48 </important>
50 <para>Some key technical points of how the <xref linkend="chapter05"/> build
51 method works:</para>
53 <itemizedlist>
54 <listitem><para>Similar in principle to cross compiling whereby tools installed
55 into the same prefix work in cooperation and thus utilize a little GNU
56 "magic".</para></listitem>
58 <listitem><para>Careful manipulation of the standard linker's library search
59 path to ensure programs are linked only against libraries we
60 choose.</para></listitem>
62 <listitem><para>Careful manipulation of <userinput>gcc</userinput>'s
63 <emphasis>specs</emphasis> file to tell the compiler which target dynamic
64 linker will be used.</para></listitem>
65 </itemizedlist>
67 <para>Binutils is installed first because both GCC and Glibc perform various
68 feature tests on the assembler and linker during their respective runs of
69 <userinput>./configure</userinput> to determine which software features to enable
70 or disable. This is more important than one might first realize. An incorrectly
71 configured GCC or Glibc can result in a subtly broken toolchain where the impact
72 of such breakage might not show up until near the end of the build of a whole
73 distribution. Thankfully, a test suite failure will usually alert us before too
74 much time is wasted.</para>
76 <para>Binutils installs its assembler and linker into two locations,
77 <filename class="directory">/tools/bin</filename> and
78 <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality,
79 the tools in one location are hard linked to the other. An important facet of
80 the linker is its library search order. Detailed information can be obtained
81 from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis>
82 flag. For example: <userinput>'ld --verbose | grep SEARCH'</userinput> will
83 show you the current search paths and their order. You can see what files are
84 actually linked by <userinput>ld</userinput> by compiling a dummy program and
85 passing the <emphasis>--verbose</emphasis> switch. For example:
86 <userinput>'gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded'</userinput>
87 will show you all the files successfully opened during the link.</para>
89 <para>The next package installed is GCC and during its run of
90 <userinput>./configure</userinput> you'll see, for example:</para>
92 <blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
93 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote>
95 <para>This is important for the reasons mentioned above. It also demonstrates
96 that GCC's configure script does not search the $PATH directories to find which
97 tools to use. However, during the actual operation of <userinput>gcc</userinput>
98 itself, the same search paths are not necessarily used. You can find out which
99 standard linker <userinput>gcc</userinput> will use by running:
100 <userinput>'gcc -print-prog-name=ld'</userinput>.
101 Detailed information can be obtained from <userinput>gcc</userinput> by passing
102 it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
103 example: <userinput>'gcc -v dummy.c'</userinput> will show you detailed
104 information about the preprocessor, compilation and assembly stages, including
105 <userinput>gcc</userinput>'s include search paths and their order.</para>
107 <para>The next package installed is Glibc. The most important considerations for
108 building Glibc are the compiler, binary tools and kernel headers. The compiler
109 is generally no problem as Glibc will always use the <userinput>gcc</userinput>
110 found in a $PATH directory. The binary tools and kernel headers can be a little
111 more troublesome. Therefore we take no risks and use the available configure
112 switches to enforce the correct selections. After the run of
113 <userinput>./configure</userinput> you can check the contents of the
114 <filename>config.make</filename> file in the
115 <filename class="directory">glibc-build</filename> directory for all the
116 important details. You'll note some interesting items like the use of
117 <userinput>CC="gcc -B/tools/bin/"</userinput> to control which binary tools are
118 used, and also the use of the <emphasis>-nostdinc</emphasis> and
119 <emphasis>-isystem</emphasis> flags to control the compiler's include search
120 path. These items help to highlight an important aspect of the Glibc package:
121 it is very self-sufficient in terms of its build machinery and generally does
122 not rely on toolchain defaults.</para>
124 <para>After the Glibc installation, we make some adjustments to ensure that
125 searching and linking take place only within our <filename>/tools</filename>
126 prefix. We install an adjusted <userinput>ld</userinput>, which has a hard-wired
127 search path limited to <filename class="directory">/tools/lib</filename>. Then
128 we amend <userinput>gcc</userinput>'s specs file to point to our new dynamic
129 linker in <filename class="directory">/tools/lib</filename>. This last step is
130 <emphasis>vital</emphasis> to the whole process. As mentioned above, a
131 hard-wired path to a dynamic linker is embedded into every ELF shared
132 executable. You can inspect this by running:
133 <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>.
134 By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
135 program compiled from here through the end of <xref linkend="chapter05"/> will
136 use our new dynamic linker in
137 <filename class="directory">/tools/lib</filename>.</para>
139 <para>The need to use the new dynamic linker is also the reason why we apply the
140 Specs patch for the second pass of GCC. Failure to do so will result in the GCC
141 programs themselves having the name of the dynamic linker from the host system's
142 <filename class="directory">/lib</filename> directory embedded into them, which
143 would defeat our goal of getting away from the host.</para>
145 <para>During the second pass of Binutils, we are able to utilize the
146 <emphasis>--with-lib-path</emphasis> configure switch to control
147 <userinput>ld</userinput>'s library search path. From this point onwards, the
148 core toolchain is self-contained and self-hosted. The remainder of the
149 <xref linkend="chapter05"/> packages all build against the new Glibc in
150 <filename class="directory">/tools</filename> and all is well.</para>
152 <para>Upon entering the chroot environment in <xref linkend="chapter06"/>, the
153 first major package we install is Glibc, due to its self-sufficient nature that
154 we mentioned above. Once this Glibc is installed into
155 <filename class="directory">/usr</filename>, we perform a quick changeover of
156 the toolchain defaults, then proceed for real in building the rest of the
157 target <xref linkend="chapter06"/> LFS system.</para>
159 <sect2>
160 <title>Notes on static linking</title>
162 <para>Most programs have to perform, beside their specific task, many rather
163 common and sometimes trivial operations. These include allocating memory,
164 searching directories, reading and writing files, string handling, pattern
165 matching, arithmetic and many other tasks. Instead of obliging each program to
166 reinvent the wheel, the GNU system provides all these basic functions in
167 ready-made libraries. The major library on any Linux system is
168 <emphasis>Glibc</emphasis>.</para>
170 <para>There are two primary ways of linking the functions from a library to a
171 program that uses them: statically or dynamically. When a program is linked
172 statically, the code of the used functions is included in the executable,
173 resulting in a rather bulky program. When a program is dynamically linked, what
174 is included is a reference to the dynamic linker, the name of the library, and
175 the name of the function, resulting in a much smaller executable. (A third way
176 is to use the programming interface of the dynamic linker. See the
177 <emphasis>dlopen</emphasis> man page for more information.)</para>
179 <para>Dynamic linking is the default on Linux and has three major advantages
180 over static linking. First, you need only one copy of the executable library
181 code on your hard disk, instead of having many copies of the same code included
182 into a whole bunch of programs -- thus saving disk space. Second, when several
183 programs use the same library function at the same time, only one copy of the
184 function's code is required in core -- thus saving memory space. Third, when a
185 library function gets a bug fixed or is otherwise improved, you only need to
186 recompile this one library, instead of having to recompile all the programs that
187 make use of the improved function.</para>
189 <para>If dynamic linking has several advantages, why then do we statically link
190 the first two packages in this chapter? The reasons are threefold: historical,
191 educational, and technical. Historical, because earlier versions of LFS
192 statically linked every program in this chapter. Educational, because knowing
193 the difference is useful. Technical, because we gain an element of independence
194 from the host in doing so, meaning that those programs can be used
195 independently of the host system. However, it's worth noting that an overall
196 successful LFS build can still be achieved when the first two packages are
197 built dynamically.</para>
199 </sect2>
201 </sect1>