|
|
@@ -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>
|
|
|
|
Bruce Dubbs