diff options
Diffstat (limited to 'chapter05/toolchaintechnotes.xml')
| -rw-r--r-- | chapter05/toolchaintechnotes.xml | 54 |
1 files changed, 28 insertions, 26 deletions
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index 376337662..9e582e345 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -16,13 +16,14 @@ 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> + <para>The overall goal of this chapter and <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> <para>The build process is based on the process of <emphasis>cross-compilation</emphasis>. Cross-compilation is normally used @@ -143,7 +144,7 @@ appearing, that proved insufficient. The word <quote>triplet</quote> remained. A simple way to determine your machine triplet is to run the <command>config.guess</command> - script that comes with the source for many packages. Unpack the Binutils + 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 32-bit Intel processor the output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit @@ -151,7 +152,7 @@ <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 + 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 @@ -168,9 +169,9 @@ <para>In order to fake a cross compilation, the name of the host triplet is slightly adjusted by changing the "vendor" field in the <envar>LFS_TGT</envar> variable. We also use the - <parameter>--with-sysroot</parameter> when building the cross linker and - cross compiler, to tell them where to find the needed host files. This - ensures none of the other programs built in <xref + <parameter>--with-sysroot</parameter> option when building the cross linker and + cross compiler to tell them where to find the needed host files. This + ensures that none of the other programs built in <xref linkend="chapter-temporary-tools"/> can link to libraries on the build machine. Only two stages are mandatory, and one more for tests:</para> @@ -215,7 +216,7 @@ internal library is named libgcc, and must be linked to the glibc library to be fully functional! Furthermore, the standard library for C++ (libstdc++) also needs being linked to glibc. The solution - to this chicken and egg problem is to first build a degraded cc1+libgcc, + to this chicken and egg problem is to first build a degraded cc1 based libgcc, lacking some fuctionalities such as threads and exception handling, then build glibc using this degraded compiler (glibc itself is not degraded), then build libstdc++. But this last library will lack the @@ -225,8 +226,8 @@ paragraph is that cc1 is unable to build a fully functional libstdc++, but this is the only compiler available for building the C/C++ libraries during stage 2! Of course, the compiler built during stage 2, cc-lfs, - would be able to build those libraries, but (i) the build system of - gcc does not know that it is usable on pc, and (ii) using it on pc + would be able to build those libraries, but (1) the build system of + gcc does not know that it is usable on pc, and (2) using it on pc would be at risk of linking to the pc libraries, since cc-lfs is a native compiler. So we have to build libstdc++ later, in chroot.</para> @@ -306,17 +307,18 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute package—it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults.</para> - <para>As said above, the standard C++ library is compiled next, followed - by all the programs that need themselves to be built. The install step - uses the <envar>DESTDIR</envar> variable to have the programs land into - the LFS filesystem.</para> - - <para>Then the native lfs compiler is built. First Binutils Pass 2, with - the same <envar>DESTDIR</envar> install as the other programs, then the - second pass of GCC, omitting libstdc++ and other non-important libraries. - Due to some weird logic in GCC's configure script, - <envar>CC_FOR_TARGET</envar> ends up as <command>cc</command> when host - is the same as target, but is different from build. This is why + <para>As said above, the standard C++ library is compiled next, followed in + Chapter 6 by all the programs that need themselves to be built. The install + step of libstdc++ uses the <envar>DESTDIR</envar> variable to have the + programs land into the LFS filesystem.</para> + + <para>In Chapter 7 the native lfs compiler is built. First binutils-pass2, + with the same <envar>DESTDIR</envar> install as the other programs is + built, and then the second pass of GCC is constructed, omitting libstdc++ + and other non-important libraries. Due to some weird logic in GCC's + configure script, <envar>CC_FOR_TARGET</envar> ends up as + <command>cc</command> when the host is the same as the target, but is + different from the build system. This is why <parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter> is put explicitely into the configure options.</para> |