Various text fixes:

- a wrong chapter in toolchain notes, and various text precisions
the option explanations of chapter 8 glibc (was labelled WIP)

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@11961 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Pierre Labastie 2020-06-19 08:13:06 +00:00
parent 8072d3da76
commit c68e018aab
3 changed files with 22 additions and 25 deletions

View File

@ -65,22 +65,9 @@ cd build</userinput></screen>
--with-headers=/usr/include \
libc_cv_slibdir=/lib</userinput></screen>
<!-- WIP -->
<variablelist>
<title>The meaning of the options and new configure parameters:</title>
<!--
<varlistentry>
<term><parameter>CC="gcc -ffile-prefix-map=$LFS_DIR=$DIR"</parameter></term>
<listitem>
<para>Make GCC record any references to files in <filename
class="directory">/usr/lib/gcc/x86_64-lfs-linux-gnu</filename>
in result of the compilation as if the files resided in <filename
class="directory">/usr/lib/gcc/x86_64-pc-linux-gnu</filename>.
This avoids introduction of invalid paths in debugging
symbols.</para>
</listitem>
</varlistentry>
-->
<title>The meaning of the configure options:</title>
<varlistentry>
<term><parameter>--disable-werror</parameter></term>
<listitem>
@ -89,6 +76,16 @@ cd build</userinput></screen>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--enable-kernel=&min-kernel;</parameter></term>
<listitem>
<para>This option tells the build system that this glibc may
be used with kernels as old as &min-kernel;. This means generating
workarounds in case a system call introduced in a later version
cannot be used.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--enable-stack-protector=strong</parameter></term>
<listitem>

View File

@ -1,13 +1,13 @@
<!ENTITY version "SVN-20200618">
<!ENTITY version "SVN-20200619">
<!ENTITY short-version "svn"> <!-- Used below in &blfs-book;
Change to x.y for release but not -rc releases -->
<!ENTITY generic-version "development"> <!-- Use "development" or "x.y[-pre{x}]" -->
<!ENTITY versiond "20200618-systemd">
<!ENTITY versiond "20200619-systemd">
<!ENTITY short-versiond "systemd">
<!ENTITY generic-versiond "systemd">
<!ENTITY releasedate "June 18th, 2020">
<!ENTITY releasedate "June 19th, 2020">
<!ENTITY copyrightdate "1999-2020"><!-- jhalfs needs a literal dash, not &ndash; -->

View File

@ -309,15 +309,15 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
and generally does not rely on toolchain defaults.</para>
<para>As said above, the standard C++ library is compiled next, followed in
<xref linkend="chapter-cross-tools"/> by all the programs that need
themselves to be built. The install
step of libstdc++ uses the <envar>DESTDIR</envar> variable to have the
<xref linkend="chapter-temporary-tools"/> by all the programs that need
themselves to be built. The install step of all those packages uses the
<envar>DESTDIR</envar> variable to have the
programs land into the LFS filesystem.</para>
<para>In <xref linkend="chapter-temporary-tools"/> 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++
<para>At the end of <xref linkend="chapter-temporary-tools"/> the native
lfs compiler is installed. First binutils-pass2 is built,
with the same <envar>DESTDIR</envar> install as the other programs,
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