source: chapter05/toolchaintechnotes.xml@ 72f3ca7

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 11.1 11.1-rc1 7.10 7.10-rc1 7.2 7.2-rc1 7.3 7.3-rc1 7.4 7.4-rc1 7.4-rc2 7.5 7.5-SYSTEMD-rc1 7.5-rc1 7.5-systemd 7.5-systemd-rc1 7.6 7.6-rc1 7.6-systemd 7.6-systemd-rc1 7.6-systemd-rc2 7.7 7.7-rc1 7.7-systemd 7.7-systemd-rc1 7.8 7.8-rc1 7.8-systemd 7.9 7.9-rc1 7.9-rc2 7.9-systemd 7.9-systemd-rc1 7.9-systemd-rc2 8.0 8.0-rc1 8.1 8.1-rc1 8.1-rc2 8.2 8.2-rc1 8.3 8.3-rc1 8.3-rc2 8.4 8.4-rc1 9.0 9.0-rc1 9.1 9.1-rc1 BOOK.old arm cross-chap5 hybrid ml-11.0 multilib nosym old-trunk systemd test trunk xry111/clfs-ng xry111/git-transition xry111/glibc-2.34 xry111/lfs-next xry111/tester-nohack xry111/usr-move
Last change on this file since 72f3ca7 was 72f3ca7, checked in by Bruce Dubbs <bdubbs@…>, 10 years ago

Various minor text changes to both book and bootscripts.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@9842 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

  • Property mode set to 100644
File size: 9.0 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % general-entities SYSTEM "../general.ent">
5 %general-entities;
6]>
7
8<sect1 id="ch-tools-toolchaintechnotes">
9 <?dbhtml filename="toolchaintechnotes.html"?>
10
11 <title>Toolchain Technical Notes</title>
12
13 <para>This section explains some of the rationale and technical details
14 behind the overall build method. It is not essential to immediately
15 understand everything in this section. Most of this information will be
16 clearer after performing an actual build. This section can be referred
17 to at any time during the process.</para>
18
19 <para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
20 produce a temporary area that contains a known-good set of tools that can be
21 isolated from the host system. By using <command>chroot</command>, the
22 commands in the remaining chapters will be contained within that environment,
23 ensuring a clean, trouble-free build of the target LFS system. The build
24 process has been designed to minimize the risks for new readers and to provide
25 the most educational value at the same time.</para>
26
27 <note>
28 <para>Before continuing, be aware of the name of the working platform,
29 often referred to as the target triplet. A simple way to determine the
30 name of the target triplet is to run the <command>config.guess</command>
31 script that comes with the source for many packages. Unpack the Binutils
32 sources and run the script: <userinput>./config.guess</userinput> and note
33 the output. For example, for a modern 32-bit Intel processor the
34 output will likely be <emphasis>i686-pc-linux-gnu</emphasis>.</para>
35
36 <para>Also be aware of the name of the platform's dynamic linker, often
37 referred to as the dynamic loader (not to be confused with the standard
38 linker <command>ld</command> that is part of Binutils). The dynamic linker
39 provided by Glibc finds and loads the shared libraries needed by a program,
40 prepares the program to run, and then runs it. The name of the dynamic
41 linker for a 32-bit Intel machine will be
42 <filename class="libraryfile">ld-linux.so.2</filename>.
43 A sure-fire way to determine the name of the dynamic linker is to
44 inspect a random binary from the host system by running:
45 <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>
46 and noting the output. The authoritative reference covering all platforms
47 is in the <filename>shlib-versions</filename> file in the root of the Glibc
48 source tree.</para>
49 </note>
50
51 <para>Some key technical points of how the <xref
52 linkend="chapter-temporary-tools"/> build method works:</para>
53
54 <itemizedlist>
55 <listitem>
56 <para>Slightly adjusting the name of the working platform, by changing the
57 &quot;vendor&quot; field target triplet by way of the
58 <envar>LFS_TGT</envar> variable, ensures that the first build of Binutils
59 and GCC produces a compatible cross-linker and cross-compiler. Instead of
60 producing binaries for another architecture, the cross-linker and
61 cross-compiler will produce binaries compatible with the current
62 hardware.</para>
63 </listitem>
64 <listitem>
65 <para> The temporary libraries are cross-compiled. Because a
66 cross-compiler by its nature cannot rely on anything from its host
67 system, this method removes potential contamination of the target
68 system by lessening the chance of headers or libraries from the host
69 being incorporated into the new tools. Cross-compilation also allows for
70 the possibility of building both 32-bit and 64-bit libraries on 64-bit
71 capable hardware.</para>
72 </listitem>
73 <listitem>
74 <para>Careful manipulation of the GCC source tells the compiler which target
75 dynamic linker will be used.</para>
76 </listitem>
77 </itemizedlist>
78
79 <para>Binutils is installed first because the <command>configure</command>
80 runs of both GCC and Glibc perform various feature tests on the assembler
81 and linker to determine which software features to enable or disable. This
82 is more important than one might first realize. An incorrectly configured
83 GCC or Glibc can result in a subtly broken toolchain, where the impact of
84 such breakage might not show up until near the end of the build of an
85 entire distribution. A test suite failure will usually highlight this error
86 before too much additional work is performed.</para>
87
88 <para>Binutils installs its assembler and linker in two locations,
89 <filename class="directory">/tools/bin</filename> and <filename
90 class="directory">/tools/$LFS_TGT/bin</filename>. The tools in one
91 location are hard linked to the other. An important facet of the linker is
92 its library search order. Detailed information can be obtained from
93 <command>ld</command> by passing it the <parameter>--verbose</parameter>
94 flag. For example, an <userinput>ld --verbose | grep SEARCH</userinput>
95 will illustrate the current search paths and their order. It shows which
96 files are linked by <command>ld</command> by compiling a dummy program and
97 passing the <parameter>--verbose</parameter> switch to the linker. For example,
98 <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
99 will show all the files successfully opened during the linking.</para>
100
101 <para>The next package installed is GCC. An example of what can be
102 seen during its run of <command>configure</command> is:</para>
103
104<screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
105checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
106
107 <para>This is important for the reasons mentioned above. It also demonstrates
108 that GCC's configure script does not search the PATH directories to find which
109 tools to use. However, during the actual operation of <command>gcc</command>
110 itself, the same search paths are not necessarily used. To find out which
111 standard linker <command>gcc</command> will use, run:
112 <userinput>gcc -print-prog-name=ld</userinput>.</para>
113
114 <para>Detailed information can be obtained from <command>gcc</command> by
115 passing it the <parameter>-v</parameter> command line option while compiling
116 a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
117 detailed information about the preprocessor, compilation, and assembly stages,
118 including <command>gcc</command>'s included search paths and their order.</para>
119
120 <para>Next installed are sanitized Linux API headers. These allow the standard
121 C library (Glibc) to interface with features that the Linux kernel will
122 provide.</para>
123
124 <para>The next package installed is Glibc. The most important considerations
125 for building Glibc are the compiler, binary tools, and kernel headers. The
126 compiler is generally not an issue since Glibc will always use the compiler
127 relating to the <parameter>--host</parameter> parameter passed to its
128 configure script, e.g. in our case,
129 <command>i686-lfs-linux-gnu-gcc</command>. The binary tools and kernel
130 headers can be a bit more complicated. Therefore, take no risks and use the
131 available configure switches to enforce the correct selections. After the run
132 of <command>configure</command>, check the contents of the
133 <filename>config.make</filename> file in the <filename
134 class="directory">glibc-build</filename> directory for all important details.
135 Note the use of <parameter>CC="i686-lfs-gnu-gcc"</parameter> to control which
136 binary tools are used and the use of the <parameter>-nostdinc</parameter> and
137 <parameter>-isystem</parameter> flags to control the compiler's include
138 search path. These items highlight an important aspect of the Glibc
139 package&mdash;it is very self-sufficient in terms of its build machinery and
140 generally does not rely on toolchain defaults.</para>
141
142 <para>During the second pass of Binutils, we are able to utilize the
143 <parameter>--with-lib-path</parameter> configure switch to control
144 <command>ld</command>'s library search path.</para>
145
146 <para>For the second pass of GCC, its sources also need to be modified to
147 tell GCC to use the new dynamic linker. Failure to do so will result in the
148 GCC programs themselves having the name of the dynamic linker from the host
149 system's <filename class="directory">/lib</filename> directory embedded into
150 them, which would defeat the goal of getting away from the host. From this
151 point onwards, the core toolchain is self-contained and self-hosted. The
152 remainder of the <xref linkend="chapter-temporary-tools"/> packages all build
153 against the new Glibc in <filename
154 class="directory">/tools</filename>.</para>
155
156 <para>Upon entering the chroot environment in <xref
157 linkend="chapter-building-system"/>, the first major package to be
158 installed is Glibc, due to its self-sufficient nature mentioned above.
159 Once this Glibc is installed into <filename
160 class="directory">/usr</filename>, we will perform a quick changeover of the
161 toolchain defaults, and then proceed in building the rest of the target
162 LFS system.</para>
163
164</sect1>
Note: See TracBrowser for help on using the repository browser.