|
|
@@ -52,31 +52,36 @@
|
|
|
or to unpack the tar package, you need tar.</para>
|
|
|
|
|
|
<para><xref linkend="chapter-temporary-tools"/> also shows you how to
|
|
|
- build a first pass of the toolchain, including Binutils and GCC (first pass
|
|
|
- basically means these two core packages will be reinstalled).
|
|
|
+ build a C cross-compiling toolchain as a first step, including binutils
|
|
|
+ and GCC. Cross-compiling is not absolutely needed since the machine we'll
|
|
|
+ run LFS on is the same as the one we build on, but it has the advantage
|
|
|
+ of clearly separating the already installed system and the future LFS one.
|
|
|
The next step is to build Glibc, the C library. Glibc will be compiled by
|
|
|
- the toolchain programs built in the first pass. Then, a second pass of the
|
|
|
- toolchain will be built. This time, the toolchain will be dynamically linked
|
|
|
- against the newly built Glibc. The remaining <xref
|
|
|
- linkend="chapter-temporary-tools"/> packages are built using this second
|
|
|
- pass toolchain. When this is done, the LFS installation process will no
|
|
|
- longer depend on the host distribution, with the exception of the running
|
|
|
- kernel. </para>
|
|
|
+ the toolchain programs built previously. Then, the missing bits for a
|
|
|
+ C++ cross-compiling toolchain will be built. It is then possible to build
|
|
|
+ packages that are needed to resolve circular dependencies in such a way
|
|
|
+ that the produced executables and libraries are completely independent
|
|
|
+ from the installed distribution.</para>
|
|
|
+
|
|
|
+ <para>The remainder of <xref linkend="chapter-temporary-tools"/> adds
|
|
|
+ the packages necessary to get a complete build environment. This is done
|
|
|
+ after running the <command>chroot</command> (change root) program to enter
|
|
|
+ a virtual environment and start a new shell whose root directory will be
|
|
|
+ set to the LFS partition. This is very similar to rebooting and instructing
|
|
|
+ the kernel to mount the LFS partition as the root partition. The system
|
|
|
+ does not actually reboot, but instead uses <command>chroot</command>
|
|
|
+ because creating a bootable system requires additional work which is not
|
|
|
+ ecessary just yet. The major advantage is that <quote>chrooting</quote>
|
|
|
+ allows to isolate the build process from the installed distribution, while
|
|
|
+ using the installed kernel.</para>
|
|
|
|
|
|
<para>This effort to isolate the new system from the host distribution may
|
|
|
seem excessive. A full technical explanation as to why this is done is
|
|
|
provided in <xref linkend="ch-tools-toolchaintechnotes"/>.</para>
|
|
|
|
|
|
- <para><xref linkend="chapter-building-system"/> begins with installing the
|
|
|
- remaining packages needed to build and test the final toolchain. Then, the
|
|
|
- full LFS system is built. But first, the <command>chroot</command> (change
|
|
|
- root) program is used to enter a virtual environment and start a new shell
|
|
|
- whose root directory will be set to the LFS partition. This is very similar
|
|
|
- to rebooting and instructing the kernel to mount the LFS partition as the
|
|
|
- root partition. The system does not actually reboot, but instead uses
|
|
|
- <command>chroot</command> because creating a bootable system requires
|
|
|
- additional work which is not necessary just yet. The major advantage is
|
|
|
- that <quote>chrooting</quote> allows you to continue using the host system
|
|
|
+ <para>In <xref linkend="chapter-building-system"/>, The
|
|
|
+ full LFS system is built. Another advantage provided by the chroot
|
|
|
+ environment is that it allows you to continue using the host system
|
|
|
while LFS is being built. While waiting for package compilations to
|
|
|
complete, you can continue using your computer as normal.</para>
|
|
|
|
Pierre Labastie