gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-01-18 13:07:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Edited for clarity, punctuation, and English idiom.

Browse Source
This commit is contained in:
David Bryant 2022-11-03 13:12:33 -05:00
parent 2c8cb1743e
commit f84d8a6f28
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
part3intro/toolchaintechnotes.xml
View File

@ -201,7 +201,7 @@
is slightly adjusted by changing the "vendor" field in the
<envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use the
<parameter>--with-sysroot</parameter> option when building the cross-linker and
cross-compiler to tell them where to find the needed host files. This
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, plus one more for tests.</para>
@ -238,8 +238,8 @@
on a machine using the already installed distribution. <quote>On
lfs</quote> means the commands are run in a chrooted environment.</para>
<para>Now, there is more about cross-compiling: the C language is not
just a compiler, but also defines a standard library. In this book, the
<para>This is not yet the end of the story. The C language is not
merely a compiler; it also defines a standard library. In this book, the
GNU C library, named glibc, is used (there is an alternative, &quot;musl&quot;). This library must
be compiled for the LFS machine; that is, using the cross-compiler cc1.
But the compiler itself uses an internal library providing complex
@ -256,22 +256,22 @@
<para>The upshot of the preceding paragraph is that cc1 is unable to
build a fully functional libstdc++ with the degraded libgcc, but cc1
is the only compiler available for building the C/C++ libraries
during stage 2. Of course, the compiler built by stage 2, cc-lfs,
would be able to build those libraries, but:</para>
during stage 2. There are two reasons we don't immediately use the
compiler built in stage 2, cc-lfs, to build those libraries.</para>
<itemizedlist>
<listitem>
<para>
Generally cc-lfs cannot run on pc (the host distro). Despite the
triplets of pc and lfs are compatible to each other, an executable
for lfs will depend on glibc-&glibc-version; while the host distro
may utilize a different libc implementation (for example, musl) or
Generally speaking, cc-lfs cannot run on pc (the host system). Even though the
triplets for pc and lfs are compatible with each other, an executable
for lfs must depend on glibc-&glibc-version;; the host distro
may utilize either a different implementation of libc (for example, musl), or
a previous release of glibc (for example, glibc-2.13).
</para>
</listitem>
<listitem>
<para>
Even if cc-lfs happens to run on pc, using it on pc would create
Even if cc-lfs can run on pc, using it on pc would create
a risk of linking to the pc libraries, since cc-lfs is a native
compiler.
</para>
@ -279,16 +279,16 @@
</itemizedlist>
<para>So when we build gcc stage 2, we instruct the building system to
rebuild libgcc and libstdc++ with cc1, but link libstdc++ to the newly
rebuilt libgcc instead of the degraded build. Then the rebuilt
libstdc++ will be fully functional.</para>
rebuild libgcc and libstdc++ with cc1, but we link libstdc++ to the newly
rebuilt libgcc instead of the old, degraded build. This makes the rebuilt
libstdc++ fully functional.</para>
<para>In &ch-final; (or <quote>stage 3</quote>), all the packages needed for
the LFS system are built. Even if a package has already been installed into
the LFS system in a previous chapter, we still rebuild the package. The main reason for
rebuilding these packages is to make them stable: if we reinstall a LFS
package on a complete LFS system, the installed content of the package
should be the same as the content of the same package when installed in
rebuilding these packages is to make them stable: if we reinstall an LFS
package on a completed LFS system, the reinstalled content of the package
should be the same as the content of the same package when first installed in
&ch-final;. The temporary packages installed in &ch-tmp-cross; or
&ch-tmp-chroot; cannot satisfy this requirement, because some of them
are built without optional dependencies, and autoconf cannot