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
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-tools-toolchaintechnotes">
<?dbhtml filename="toolchaintechnotes.html"?>
<title>Toolchain Technical Notes</title>
<para>This section explains some of the rationale and technical details
behind the overall build method. It is not essential to immediately
understand everything in this section. Most of this information will be
clearer after performing an actual build. This section can be referred
to at any time during the process.</para>
<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
produce a temporary area that contains a known-good set of tools that can be
isolated from the host system. By using <command>chroot</command>, the
commands in the remaining chapters will be contained within that environment,
ensuring a clean, trouble-free build of the target LFS system. The build
process has been designed to minimize the risks for new readers and to provide
the most educational value at the same time.</para>
<important>
<para>Before continuing, be aware of the name of the working platform,
often referred to as the target triplet. A simple way to determine the
name of the target triplet is to run the <command>config.guess</command>
script that comes with the source for many packages. Unpack the Binutils
sources and run the script: <userinput>./config.guess</userinput> and note
the output. For example, for a modern 32-bit Intel processor the
output will likely be <emphasis>i686-pc-linux-gnu</emphasis>.</para>
<para>Also be aware of the name of the platform's dynamic linker, often
referred to as the dynamic loader (not to be confused with the standard
linker <command>ld</command> that is part of Binutils). The dynamic linker
provided by Glibc finds and loads the shared libraries needed by a program,
prepares the program to run, and then runs it. The name of the dynamic
linker for a 32-bit Intel machine will be
<filename class="libraryfile">ld-linux.so.2</filename>.
A sure-fire way to determine the name of the dynamic linker is to
inspect a random binary from the host system by running:
<userinput>readelf -l <name of binary> | grep interpreter</userinput>
and noting the output. The authoritative reference covering all platforms
is in the <filename>shlib-versions</filename> file in the root of the Glibc
source tree.</para>
</important>
<para>Some key technical points of how the <xref
linkend="chapter-temporary-tools"/> build method works:</para>
<itemizedlist>
<listitem>
<para>Slightly adjusting the name of the working platform, by changing the
"vendor" field target triplet by way of the
<envar>LFS_TGT</envar> variable, ensures that the first build of Binutils
and GCC produces a compatible cross-linker and cross-compiler. Instead of
producing binaries for another architecture, the cross-linker and
cross-compiler will produce binaries compatible with the current
hardware.</para>
</listitem>
<listitem>
<para> The temporary libraries are cross-compiled. Because a
cross-compiler by its nature cannot rely on anything from its host
system, this method removes potential contamination of the target
system by lessening the chance of headers or libraries from the host
being incorporated into the new tools. Cross-compilation also allows for
the possibility of building both 32-bit and 64-bit libraries on 64-bit
capable hardware.</para>
</listitem>
<listitem>
<para>Careful manipulation of <command>gcc</command>'s
<filename>specs</filename> file tells the compiler which target dynamic
linker will be used</para>
</listitem>
</itemizedlist>
<para>Binutils is installed first because the <command>configure</command>
runs of both GCC and Glibc perform various feature tests on the assembler
and linker to determine which software features to enable or disable. This
is more important than one might first realize. An incorrectly configured
GCC or Glibc can result in a subtly broken toolchain, where the impact of
such breakage might not show up until near the end of the build of an
entire distribution. A test suite failure will usually highlight this error
before too much additional work is performed.</para>
<para>Binutils installs its assembler and linker in two locations,
<filename class="directory">/tools/bin</filename> and <filename
class="directory">/tools/$LFS_TGT/bin</filename>. The tools in one
location are hard linked to the other. An important facet of the linker is
its library search order. Detailed information can be obtained from
<command>ld</command> by passing it the <parameter>--verbose</parameter>
flag. For example, an <userinput>ld --verbose | grep SEARCH</userinput>
will illustrate the current search paths and their order. It shows which
files are linked by <command>ld</command> by compiling a dummy program and
passing the <parameter>--verbose</parameter> switch to the linker. For example,
<userinput>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</userinput>
will show all the files successfully opened during the linking.</para>
<para>The next package installed is GCC. An example of what can be
seen during its run of <command>configure</command> is:</para>
<screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
<para>This is important for the reasons mentioned above. It also demonstrates
that GCC's configure script does not search the PATH directories to find which
tools to use. However, during the actual operation of <command>gcc</command>
itself, the same search paths are not necessarily used. To find out which
standard linker <command>gcc</command> will use, run:
<userinput>gcc -print-prog-name=ld</userinput>.</para>
<para>Detailed information can be obtained from <command>gcc</command> by
passing it the <parameter>-v</parameter> command line option while compiling
a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
detailed information about the preprocessor, compilation, and assembly stages,
including <command>gcc</command>'s included search paths and their order.</para>
<para>The next package installed is Glibc. The most important considerations
for building Glibc are the compiler, binary tools, and kernel headers. The
compiler is generally not an issue since Glibc will always use the compiler
relating to the <parameter>--host</parameter> parameter passed to its
configure script, e.g. in our case,
<command>i686-lfs-linux-gnu-gcc</command>. The binary tools and kernel
headers can be a bit more complicated. Therefore, take no risks and use the
available configure switches to enforce the correct selections. After the run
of <command>configure</command>, check the contents of the
<filename>config.make</filename> file in the <filename
class="directory">glibc-build</filename> directory for all important details.
Note the use of <parameter>CC="i686-lfs-gnu-gcc"</parameter> to control which
binary tools are used and the use of the <parameter>-nostdinc</parameter> and
<parameter>-isystem</parameter> flags to control the compiler's include
search path. These items highlight an important aspect of the Glibc
package—it is very self-sufficient in terms of its build machinery and
generally does not rely on toolchain defaults.</para>
<para>After the Glibc installation, change <command>gcc</command>'s specs file
to point to the new dynamic linker in <filename
class="directory">/tools/lib</filename>. This last step is vital in ensuring
that searching and linking take place only within the <filename
class="directory">/tools</filename> prefix. A hard-wired
path to a dynamic linker is embedded into every Executable and Link Format
(ELF)-shared executable. This can be inspected by running:
<userinput>readelf -l <name of binary> | grep interpreter</userinput>.
Amending <command>gcc</command>'s specs file ensures that every program
compiled from here through the end of this chapter will use the new dynamic
linker in <filename class="directory">/tools/lib</filename>.</para>
<para>For the second pass of GCC, its sources also need to be modified
to tell GCC to use the new dynamic linker. Failure to do
so will result in the GCC programs themselves having the name of the
dynamic linker from the host system's <filename
class="directory">/lib</filename> directory embedded into them, which
would defeat the goal of getting away from the host.</para>
<para>During the second pass of Binutils, we are able to utilize the
<parameter>--with-lib-path</parameter> configure switch to control
<command>ld</command>'s library search path. From this point onwards,
the core toolchain is self-contained and self-hosted. The remainder of
the <xref linkend="chapter-temporary-tools"/> packages all build against
the new Glibc in <filename class="directory">/tools</filename>.</para>
<para>Upon entering the chroot environment in <xref
linkend="chapter-building-system"/>, the first major package to be
installed is Glibc, due to its self-sufficient nature mentioned above.
Once this Glibc is installed into <filename
class="directory">/usr</filename>, we will perform a quick changeover of the
toolchain defaults, and then proceed in building the rest of the target
LFS system.</para>
<!-- FIXME: Removed as part of the fix for bug 1061 - we no longer build pass1
packages statically, therefore this explanation isn't required
<sect2>
<title>Notes on Static Linking</title>
<para>Besides their specific task, most programs have to perform many
common and sometimes trivial operations. These include allocating
memory, searching directories, reading and writing files, string
handling, pattern matching, arithmetic, and other tasks. Instead of
obliging each program to reinvent the wheel, the GNU system provides
all these basic functions in ready-made libraries. The major library
on any Linux system is Glibc.</para>
<para>There are two primary 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, it includes a reference to the
dynamic linker, the name of the library, and the name of the function,
resulting in a much smaller executable. A third option is to use the
programming interface of the dynamic linker (see <filename>dlopen(3)</filename>
for more information).</para>
<para>Dynamic linking is the default on Linux and has three major
advantages over static linking. First, only one copy of the executable
library code is needed on the hard disk, instead of having multiple
copies of the same code included in several 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. Third, when a library
function gets a bug fixed or is otherwise improved, only the one
library needs to be recompiled instead of recompiling all programs
that make use of the improved function.</para>
<para>If dynamic linking has several advantages, why then do we
statically link the first two packages in this chapter? The reasons
are threefold—historical, educational, and technical. The
historical reason is that earlier versions of LFS statically linked
every program in this chapter. Educationally, knowing the difference
between static and dynamic linking is useful. The technical benefit is
a gained element of independence from the host, meaning that those
programs can be used independently of the host system. However, it is
worth noting that an overall successful LFS build can still be
achieved when the first two packages are built dynamically.</para>
</sect2>-->
</sect1>
|
