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

Merge remote-tracking branch 'origin/trunk' into xry111/arm64

Browse Source
This commit is contained in:
Xi Ruoyao 2022-10-31 14:58:31 +08:00
commit 9974e9b18c
No known key found for this signature in database
GPG Key ID: ACAAD20E19E710E3
10 changed files with 149 additions and 123 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
appendices/dependencies.xml
View File

@ -2998,14 +2998,14 @@
<segtitle>&dependencies;</segtitle> <segtitle>&dependencies;</segtitle>
<seglistitem> <seglistitem>
<seg>Bash, Binutils, Coreutils, Diffutils, Eudev, Findutils, Gawk, <seg>Bash, Binutils, Coreutils, Diffutils, Eudev, Findutils, Gawk,
GCC, Gettext, Glibc, Grep, Libcap, Make, Ncurses, Sed, and Zlib</seg> GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed, and Zlib</seg>
</seglistitem> </seglistitem>
</segmentedlist> </segmentedlist>
<segmentedlist id="util-linux-rundeps"> <segmentedlist id="util-linux-rundeps">
<segtitle>&runtime;</segtitle> <segtitle>&runtime;</segtitle>
<seglistitem> <seglistitem>
<seg>Glibc, Libcap, Ncurses, Readline, and Zlib</seg> <seg>Glibc, Ncurses, Readline, and Zlib</seg>
</seglistitem> </seglistitem>
</segmentedlist> </segmentedlist>
@ -3027,6 +3027,8 @@
<segtitle>&external;</segtitle> <segtitle>&external;</segtitle>
<seglistitem> <seglistitem>
<seg> <seg>
<ulink
url="https://people.redhat.com/sgrubb/libcap-ng/">Libcap-NG</ulink>,
<ulink <ulink
url="&blfs-book;postlfs/linux-pam.html">Linux-PAM</ulink> url="&blfs-book;postlfs/linux-pam.html">Linux-PAM</ulink>
and <ulink and <ulink

2
chapter01/askforhelp.xml
View File

@ -50,7 +50,7 @@
<para>The package or section the problem was encountered in</para> <para>The package or section the problem was encountered in</para>
</listitem> </listitem>
<listitem> <listitem>
<para>The exact error message, or a clear decription of the problem</para> <para>The exact error message, or a clear description of the problem</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Note whether you have deviated from the book at all </para> <para>Note whether you have deviated from the book at all </para>

4
chapter04/addinguser.xml
View File

@ -62,7 +62,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
<varlistentry> <varlistentry>
<term><parameter>lfs</parameter></term> <term><parameter>lfs</parameter></term>
<listitem> <listitem>
<para>This is the actual name for the created user.</para> <para>This is the name of the new user.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -71,7 +71,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
<para>If you want to log in as &lfs-user; or switch to &lfs-user; from a <para>If you want to log in as &lfs-user; or switch to &lfs-user; from a
non-&root; user (as opposed to switching to user &lfs-user; non-&root; user (as opposed to switching to user &lfs-user;
when logged in as &root;, which does not require the &lfs-user; user to when logged in as &root;, which does not require the &lfs-user; user to
have a password), you need to set a password of &lfs-user;. Issue the have a password), you need to set a password for &lfs-user;. Issue the
following command as the &root; user to set the password:</para> following command as the &root; user to set the password:</para>
<screen role="nodump"><userinput>passwd lfs</userinput></screen> <screen role="nodump"><userinput>passwd lfs</userinput></screen>

29
chapter04/settingenviron.xml
View File

@ -19,9 +19,9 @@
<literal>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</literal> <literal>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</literal>
EOF</userinput></screen> EOF</userinput></screen>
<para>When logged on as user <systemitem class="username">lfs</systemitem> <para>When logged on as user <systemitem class="username">lfs</systemitem>,
or switched to the &lfs-user; user using a <command>su</command> command or when switched to the &lfs-user; user using an <command>su</command> command
with <quote><parameter>-</parameter></quote> option, with the <quote><parameter>-</parameter></quote> option,
the initial shell is a <emphasis>login</emphasis> shell which reads the initial shell is a <emphasis>login</emphasis> shell which reads
the <filename>/etc/profile</filename> of the host (probably containing some the <filename>/etc/profile</filename> of the host (probably containing some
settings and environment variables) and then <filename>.bash_profile</filename>. settings and environment variables) and then <filename>.bash_profile</filename>.
@ -30,8 +30,7 @@ EOF</userinput></screen>
one with a completely empty environment, except for the <envar>HOME</envar>, one with a completely empty environment, except for the <envar>HOME</envar>,
<envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no <envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no
unwanted and potentially hazardous environment variables from the host system unwanted and potentially hazardous environment variables from the host system
leak into the build environment. The technique used here achieves the goal of leak into the build environment.</para>
ensuring a clean environment.</para>
<para>The new instance of the shell is a <emphasis>non-login</emphasis> <para>The new instance of the shell is a <emphasis>non-login</emphasis>
shell, which does not read, and execute, the contents of the <filename>/etc/profile</filename> or shell, which does not read, and execute, the contents of the <filename>/etc/profile</filename> or
@ -100,7 +99,7 @@ EOF</userinput></screen>
programs, making their messages follow the conventions of a specified country. programs, making their messages follow the conventions of a specified country.
Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote> Setting <envar>LC_ALL</envar> to <quote>POSIX</quote> or <quote>C</quote>
(the two are equivalent) ensures that everything will work as expected in (the two are equivalent) ensures that everything will work as expected in
the chroot environment.</para> the cross-compilation environment.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -108,8 +107,8 @@ EOF</userinput></screen>
<term><parameter>LFS_TGT=(uname -m)-lfs-linux-gnu</parameter></term> <term><parameter>LFS_TGT=(uname -m)-lfs-linux-gnu</parameter></term>
<listitem> <listitem>
<para>The <envar>LFS_TGT</envar> variable sets a non-default, but compatible machine <para>The <envar>LFS_TGT</envar> variable sets a non-default, but compatible machine
description for use when building our cross compiler and linker and when cross description for use when building our cross-compiler and linker and when
compiling our temporary toolchain. More information is contained in cross-compiling our temporary toolchain. More information is provided by
<xref linkend="ch-tools-toolchaintechnotes" role=""/>.</para> <xref linkend="ch-tools-toolchaintechnotes" role=""/>.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -132,7 +131,7 @@ EOF</userinput></screen>
<term><parameter>if [ ! -L /bin ]; then PATH=/bin:$PATH; fi</parameter></term> <term><parameter>if [ ! -L /bin ]; then PATH=/bin:$PATH; fi</parameter></term>
<listitem> <listitem>
<para>If <filename class="directory">/bin</filename> is not a symbolic <para>If <filename class="directory">/bin</filename> is not a symbolic
link, then it has to be added to the <envar>PATH</envar> variable.</para> link, it must be added to the <envar>PATH</envar> variable.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -163,7 +162,7 @@ EOF</userinput></screen>
<varlistentry> <varlistentry>
<term><parameter>export ...</parameter></term> <term><parameter>export ...</parameter></term>
<listitem> <listitem>
<para>While the above commands have set some variables, in order <para>While the preceding commands have set some variables, in order
to make them visible within any sub-shells, we export them.</para> to make them visible within any sub-shells, we export them.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -172,7 +171,7 @@ EOF</userinput></screen>
<important> <important>
<para>Several commercial distributions add a non-documented instantiation <para>Several commercial distributions add an undocumented instantiation
of <filename>/etc/bash.bashrc</filename> to the initialization of of <filename>/etc/bash.bashrc</filename> to the initialization of
<command>bash</command>. This file has the potential to modify the <command>bash</command>. This file has the potential to modify the
<systemitem class="username">lfs</systemitem> <systemitem class="username">lfs</systemitem>
@ -185,9 +184,9 @@ EOF</userinput></screen>
<screen role="nodump"><userinput>[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE</userinput></screen> <screen role="nodump"><userinput>[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE</userinput></screen>
<para>After use of the <systemitem class="username">lfs</systemitem> <para>When the <systemitem class="username">lfs</systemitem>
user is finished at the beginning of <xref user is no longer needed (at the beginning of <xref
linkend="chapter-chroot-temporary-tools"/>, you can restore linkend="chapter-chroot-temporary-tools"/>), you may safely restore
<filename>/etc/bash.bashrc</filename> (if desired).</para> <filename>/etc/bash.bashrc</filename> (if desired).</para>
<para>Note that the LFS Bash package we will build in <para>Note that the LFS Bash package we will build in
@ -196,7 +195,7 @@ EOF</userinput></screen>
completed LFS system.</para> completed LFS system.</para>
</important> </important>
<para>Finally, to have the environment fully prepared for building the <para>Finally, to ensure the environment is fully prepared for building the
temporary tools, force the <command>bash</command> shell to read temporary tools, force the <command>bash</command> shell to read
the new user profile:</para> the new user profile:</para>

2
chapter05/binutils-pass1.xml
View File

@ -84,7 +84,7 @@ cd build</userinput></screen>
<term><parameter>--prefix=$LFS/tools</parameter></term> <term><parameter>--prefix=$LFS/tools</parameter></term>
<listitem> <listitem>
<para>This tells the configure script to prepare to install the <para>This tells the configure script to prepare to install the
binutils programs in the <filename Binutils programs in the <filename
class="directory">$LFS/tools</filename> directory.</para> class="directory">$LFS/tools</filename> directory.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>

14
chapter05/gcc-pass1.xml
View File

@ -50,9 +50,9 @@
use them:</para> use them:</para>
<note><para>There are frequent misunderstandings about this chapter. The <note><para>There are frequent misunderstandings about this chapter. The
procedures are the same as every other chapter as explained earlier (<xref procedures are the same as every other chapter, as explained earlier (<xref
linkend='buildinstr'/>). First extract the gcc tarball from the sources linkend='buildinstr'/>). First, extract the gcc-&gcc-version; tarball from the sources
directory and then change to the directory created. Only then should you directory, and then change to the directory created. Only then should you
proceed with the instructions below.</para></note> proceed with the instructions below.</para></note>
<screen><userinput remap="pre">tar -xf ../mpfr-&mpfr-version;.tar.xz <screen><userinput remap="pre">tar -xf ../mpfr-&mpfr-version;.tar.xz
@ -103,9 +103,9 @@ cd build</userinput></screen>
<varlistentry> <varlistentry>
<term><parameter>--with-glibc-version=&glibc-version;</parameter></term> <term><parameter>--with-glibc-version=&glibc-version;</parameter></term>
<listitem> <listitem>
<para>This option specifies the version of glibc which will be <para>This option specifies the version of Glibc which will be
used on the target. It is not relevant to the libc of the host used on the target. It is not relevant to the libc of the host
distro because everything compiled by pass1 gcc will run in the distro because everything compiled by pass1 GCC will run in the
chroot environment, which is isolated from libc of the host chroot environment, which is isolated from libc of the host
distro.</para> distro.</para>
</listitem> </listitem>
@ -148,7 +148,7 @@ cd build</userinput></screen>
<term><parameter>--disable-shared</parameter></term> <term><parameter>--disable-shared</parameter></term>
<listitem> <listitem>
<para>This switch forces GCC to link its internal libraries <para>This switch forces GCC to link its internal libraries
statically. We need this because the shared libraries require glibc, statically. We need this because the shared libraries require Glibc,
which is not yet installed on the target system.</para> which is not yet installed on the target system.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -199,7 +199,7 @@ cd build</userinput></screen>
time of this build of GCC <filename>$LFS/usr/include/limits.h</filename> time of this build of GCC <filename>$LFS/usr/include/limits.h</filename>
does not exist, so the internal header that has just been installed is a does not exist, so the internal header that has just been installed is a
partial, self-contained file and does not include the extended features of partial, self-contained file and does not include the extended features of
the system header. This is adequate for building glibc, but the full the system header. This is adequate for building Glibc, but the full
internal header will be needed later. Create a full version of the internal internal header will be needed later. Create a full version of the internal
header using a command that is identical to what the GCC build system does header using a command that is identical to what the GCC build system does
in normal circumstances:</para> in normal circumstances:</para>

34
chapter05/glibc.xml
View File

@ -43,7 +43,7 @@
<sect2 role="installation"> <sect2 role="installation">
<title>Installation of Glibc</title> <title>Installation of Glibc</title>
<para>Some of the Glibc programs use the non-FHS compliant <para>Some of the Glibc programs use the non-FHS-compliant
<filename class="directory">/var/db</filename> directory to store their <filename class="directory">/var/db</filename> directory to store their
runtime data. Apply the following patch to make such programs store their runtime data. Apply the following patch to make such programs store their
runtime data in the FHS-compliant locations:</para> runtime data in the FHS-compliant locations:</para>
@ -107,7 +107,7 @@ cd build</userinput></screen>
<term><parameter>libc_cv_slibdir=/usr/lib</parameter></term> <term><parameter>libc_cv_slibdir=/usr/lib</parameter></term>
<listitem> <listitem>
<para>This ensures that the library is installed in /usr/lib instead <para>This ensures that the library is installed in /usr/lib instead
of the default /lib64 on 64 bit machines.</para> of the default /lib64 on 64-bit machines.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -125,11 +125,11 @@ cd build</userinput></screen>
<para>The missing or incompatible <command>msgfmt</command> program is <para>The missing or incompatible <command>msgfmt</command> program is
generally harmless. This <command>msgfmt</command> program is part of the generally harmless. This <command>msgfmt</command> program is part of the
Gettext package which the host distribution should provide.</para> Gettext package, which the host distribution should provide.</para>
<note><para>There have been reports that this package may fail when <note><para>There have been reports that this package may fail when
building as a "parallel make". If this occurs, rerun the make command building as a "parallel make". If that occurs, rerun the make command
with a "-j1" option.</para></note> with the "-j1" option.</para></note>
<para>Compile the package:</para> <para>Compile the package:</para>
@ -140,9 +140,9 @@ cd build</userinput></screen>
<warning><para>If <envar>LFS</envar> is not properly set, and despite the <warning><para>If <envar>LFS</envar> is not properly set, and despite the
recommendations, you are building as recommendations, you are building as
<systemitem class="username">root</systemitem>, the next command will <systemitem class="username">root</systemitem>, the next command will
install the newly built glibc to your host system, which most likely install the newly built Glibc to your host system, which will almost
will render it unusable. So double check that the environment is certainly render it unusable. So double-check that the environment is
correctly set, before running the following command.</para></warning> correctly set, and that you are not &root;, before running the following command.</para></warning>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen> <screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
@ -156,15 +156,15 @@ cd build</userinput></screen>
packages to define the location where the package should be packages to define the location where the package should be
installed. If it is not set, it defaults to the root (<filename installed. If it is not set, it defaults to the root (<filename
class="directory">/</filename>) directory. Here we specify that class="directory">/</filename>) directory. Here we specify that
the package be installed in <filename class="directory">$LFS the package is installed in <filename class="directory">$LFS
</filename>, which will become the root after <xref linkend= </filename>, which will become the root directory in <xref linkend=
"ch-tools-chroot"/>.</para> "ch-tools-chroot"/>.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>Fix hardcoded path to the executable loader in <para>Fix a hard coded path to the executable loader in the
<command>ldd</command> script:</para> <command>ldd</command> script:</para>
<screen><userinput remap="install">sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd</userinput></screen> <screen><userinput remap="install">sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd</userinput></screen>
@ -185,10 +185,10 @@ readelf -l a.out | grep ld-linux</userinput></screen>
<para>Note that for big-endian machines, the interpreter name will be <para>Note that for big-endian machines, the interpreter name will be
<filename>/lib/ld-linux-aarch64_be.so.1</filename>.</para> <filename>/lib/ld-linux-aarch64_be.so.1</filename>.</para>
<para>If the output is not shown as above or there was no output at all, <para>If the output is not as shown above, or there is no output at all,
then something is wrong. Investigate and retrace the steps to find out then something is wrong. Investigate and retrace the steps to find out
where the problem is and correct it. This issue must be resolved before where the problem is and correct it. This issue must be resolved before
continuing on.</para> continuing.</para>
<para>Once all is well, clean up the test file:</para> <para>Once all is well, clean up the test file:</para>
@ -196,14 +196,14 @@ readelf -l a.out | grep ld-linux</userinput></screen>
</caution> </caution>
<note><para>Building packages in the next chapter will serve as an <note><para>Building the packages in the next chapter will serve as an
additional check that the toolchain has been built properly. If some additional check that the toolchain has been built properly. If some
package, especially binutils-pass2 or gcc-pass2, fails to build, it is package, especially Binutils-pass2 or GCC-pass2, fails to build, it is
an indication that something has gone wrong with the an indication that something has gone wrong with the
previous Binutils, GCC, or Glibc installations.</para></note> preceding Binutils, GCC, or Glibc installations.</para></note>
<para>Now that our cross-toolchain is complete, finalize the installation <para>Now that our cross-toolchain is complete, finalize the installation
of the limits.h header. For doing so, run a utility provided by the GCC of the limits.h header. To do this, run a utility provided by the GCC
developers:</para> developers:</para>
<screen><userinput>$LFS/tools/libexec/gcc/$LFS_TGT/&gcc-version;/install-tools/mkheaders</userinput></screen> <screen><userinput>$LFS/tools/libexec/gcc/$LFS_TGT/&gcc-version;/install-tools/mkheaders</userinput></screen>

22
chapter05/libstdc++.xml
View File

@ -28,7 +28,7 @@
to compile C++ code to compile C++ code
(part of GCC is written in C++), but we had to defer its installation (part of GCC is written in C++), but we had to defer its installation
when we built <xref linkend="ch-tools-gcc-pass1"/> when we built <xref linkend="ch-tools-gcc-pass1"/>
because it depends on glibc, which was not yet available in the target because Libstdc++ depends on Glibc, which was not yet available in the target
directory. directory.
</para> </para>
@ -53,12 +53,12 @@
<filename>gcc-&gcc-version;</filename> directory.</para> <filename>gcc-&gcc-version;</filename> directory.</para>
</note> </note>
<para>Create a separate build directory for libstdc++ and enter it:</para> <para>Create a separate build directory for Libstdc++ and enter it:</para>
<screen><userinput remap="pre">mkdir -v build <screen><userinput remap="pre">mkdir -v build
cd build</userinput></screen> cd build</userinput></screen>
<para>Prepare libstdc++ for compilation:</para> <para>Prepare Libstdc++ for compilation:</para>
<screen><userinput remap="configure">../libstdc++-v3/configure \ <screen><userinput remap="configure">../libstdc++-v3/configure \
--host=$LFS_TGT \ --host=$LFS_TGT \
@ -75,7 +75,7 @@ cd build</userinput></screen>
<varlistentry> <varlistentry>
<term><parameter>--host=...</parameter></term> <term><parameter>--host=...</parameter></term>
<listitem> <listitem>
<para>Specifies that the cross compiler we have just built <para>Specifies that the cross-compiler we have just built
should be used instead of the one in should be used instead of the one in
<filename>/usr/bin</filename>.</para> <filename>/usr/bin</filename>.</para>
</listitem> </listitem>
@ -93,27 +93,27 @@ cd build</userinput></screen>
<term><parameter>--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/&gcc-version;</parameter></term> <term><parameter>--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/&gcc-version;</parameter></term>
<listitem> <listitem>
<para>This specifies the installation directory for include files. <para>This specifies the installation directory for include files.
Because libstdc++ is the standard C++ library for LFS, this Because Libstdc++ is the standard C++ library for LFS, this
directory should match the location where the C++ compiler directory should match the location where the C++ compiler
(<command>$LFS_TGT-g++</command>) would search for the (<command>$LFS_TGT-g++</command>) would search for the
standard C++ include files. In a normal build, this information standard C++ include files. In a normal build, this information
is automatically passed to the libstdc++ <command>configure</command> is automatically passed to the Libstdc++ <command>configure</command>
options from the top level directory. In our case, this information options from the top level directory. In our case, this information
must be explicitly given. must be explicitly given.
The C++ compiler will prepend the sysroot path The C++ compiler will prepend the sysroot path
<filename class="directory">$LFS</filename> (specified building <filename class="directory">$LFS</filename> (specified when building
GCC pass 1) to the include file search path, so it will actually GCC-pass1) to the include file search path, so it will actually
search in search in
<filename class="directory">$LFS/tools/$LFS_TGT/include/c++/&gcc-version;</filename>. <filename class="directory">$LFS/tools/$LFS_TGT/include/c++/&gcc-version;</filename>.
The combination of the <parameter>DESTDIR</parameter> The combination of the <parameter>DESTDIR</parameter>
variable (in the <command>make install</command> command below) variable (in the <command>make install</command> command below)
and this switch ensures to install the headers there.</para> and this switch causes the headers to be installed there.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>Compile libstdc++ by running:</para> <para>Compile Libstdc++ by running:</para>
<screen><userinput remap="make">make</userinput></screen> <screen><userinput remap="make">make</userinput></screen>
@ -122,7 +122,7 @@ cd build</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen> <screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<para>Remove the libtool archive files because they are harmful for <para>Remove the libtool archive files because they are harmful for
cross compilation:</para> cross-compilation:</para>
<screen><userinput remap="install">rm -v $LFS/usr/lib/lib{stdc++,stdc++fs,supc++}.la</userinput></screen> <screen><userinput remap="install">rm -v $LFS/usr/lib/lib{stdc++,stdc++fs,supc++}.la</userinput></screen>

147
part3intro/toolchaintechnotes.xml
View File

@ -40,8 +40,8 @@
<note> <note>
<para> <para>
The LFS book is not (and does not contain) a general tutorial to The LFS book is not (and does not contain) a general tutorial to
build a cross (or native) toolchain. Don't use the commands in the build a cross- (or native) toolchain. Don't use the commands in the
book for a cross toolchain for some purpose other book for a cross-toolchain for some purpose other
than building LFS, unless you really understand what you are doing. than building LFS, unless you really understand what you are doing.
</para> </para>
</note> </note>
@ -74,7 +74,7 @@
</variablelist> </variablelist>
<para>As an example, let us imagine the following scenario (sometimes <para>As an example, let us imagine the following scenario (sometimes
referred to as <quote>Canadian Cross</quote>): we have a referred to as <quote>Canadian Cross</quote>). We have a
compiler on a slow machine only, let's call it machine A, and the compiler compiler on a slow machine only, let's call it machine A, and the compiler
ccA. We also have a fast machine (B), but no compiler for (B), and we ccA. We also have a fast machine (B), but no compiler for (B), and we
want to produce code for a third, slow machine (C). We will build a want to produce code for a third, slow machine (C). We will build a
@ -145,32 +145,36 @@
<title>Implementation of Cross-Compilation for LFS</title> <title>Implementation of Cross-Compilation for LFS</title>
<note> <note>
<para>All packages involved with cross compilation in the book use an <para>All the cross-compiled packages in this book use an
autoconf-based building system. The autoconf-based building system autoconf-based building system. The autoconf-based building system
accepts system types in the form cpu-vendor-kernel-os, accepts system types in the form cpu-vendor-kernel-os,
referred to as the system triplet. Since the vendor field is mostly referred to as the system triplet. Since the vendor field is often
irrelevant, autoconf allows to omit it. An astute reader may wonder irrelevant, autoconf lets you omit it.</para>
<para>An astute reader may wonder
why a <quote>triplet</quote> refers to a four component name. The why a <quote>triplet</quote> refers to a four component name. The
reason is the kernel field and the os field originated from one kernel field and the os field began as a single
<quote>system</quote> field. Such a three-field form is still valid <quote>system</quote> field. Such a three-field form is still valid
today for some systems, for example today for some systems, for example,
<literal>x86_64-unknown-freebsd</literal>. But for other systems, <literal>x86_64-unknown-freebsd</literal>. But
two systems can share the same kernel but still be too different to two systems can share the same kernel and still be too different to
use a same triplet for them. For example, an Android running on a use the same triplet to describe them. For example, Android running on a
mobile phone is completely different from Ubuntu running on an ARM64 mobile phone is completely different from Ubuntu running on an ARM64
server, despite they are running on the same type of CPU (ARM64) and server, even though they are both running on the same type of CPU (ARM64) and
using the same kernel (Linux). using the same kernel (Linux).</para>
Without an emulation layer, you cannot run an
executable for the server on the mobile phone or vice versa. So the <para>Without an emulation layer, you cannot run an
<quote>system</quote> field is separated into kernel and os fields to executable for a server on a mobile phone or vice versa. So the
designate these systems unambiguously. For our example, the Android <quote>system</quote> field has been divided into kernel and os fields, to
designate these systems unambiguously. In our example, the Android
system is designated <literal>aarch64-unknown-linux-android</literal>, system is designated <literal>aarch64-unknown-linux-android</literal>,
and the Ubuntu system is designated and the Ubuntu system is designated
<literal>aarch64-unknown-linux-gnu</literal>. The word <literal>aarch64-unknown-linux-gnu</literal>.</para>
<quote>triplet</quote> remained. A simple way to determine your
<para>The word <quote>triplet</quote> remains embedded in the lexicon. A simple way to determine your
system triplet is to run the <command>config.guess</command> system 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 sources, run the script <userinput>./config.guess</userinput>, and note
the output. For example, for a 32-bit Intel processor the the output. For example, for a 32-bit Intel processor the
output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>. On most system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>. On most
@ -193,11 +197,11 @@
tree.</para> tree.</para>
</note> </note>
<para>In order to fake a cross compilation in LFS, the name of the host triplet <para>In order to fake a cross-compilation in LFS, the name of the host triplet
is slightly adjusted by changing the &quot;vendor&quot; field in the is slightly adjusted by changing the &quot;vendor&quot; field in the
<envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use 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 <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 ensures that none of the other programs built in <xref
linkend="chapter-temporary-tools"/> can link to libraries on the build linkend="chapter-temporary-tools"/> can link to libraries on the build
machine. Only two stages are mandatory, plus one more for tests.</para> machine. Only two stages are mandatory, plus one more for tests.</para>
@ -237,11 +241,11 @@
<para>Now, there is more about cross-compiling: the C language is not <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 just a compiler, but 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 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. be compiled for the LFS machine; that is, using the cross-compiler cc1.
But the compiler itself uses an internal library implementing complex But the compiler itself uses an internal library providing complex
subroutines for functions not available in the assembler instruction set. This subroutines for functions not available in the assembler instruction set. This
internal library is named libgcc, and it must be linked to the glibc internal library is named libgcc, and it must be linked to the glibc
library to be fully functional! Furthermore, the standard library for library to be fully functional. Furthermore, the standard library for
C++ (libstdc++) must also be linked with glibc. The solution to this C++ (libstdc++) must also be linked with glibc. The solution to this
chicken and egg problem is first to build a degraded cc1-based libgcc, chicken and egg problem is first to build a degraded cc1-based libgcc,
lacking some functionalities such as threads and exception handling, and then lacking some functionalities such as threads and exception handling, and then
@ -249,36 +253,55 @@
degraded), and also to build libstdc++. This last library will lack some of the degraded), and also to build libstdc++. This last library will lack some of the
functionality of libgcc.</para> functionality of libgcc.</para>
<para>This is not the end of the story: the upshot of the preceding <para>The upshot of the preceding paragraph is that cc1 is unable to
paragraph is that cc1 is unable to build a fully functional libstdc++, but build a fully functional libstdc++ with the degraded libgcc, but cc1
this is the only compiler available for building the C/C++ libraries is the only compiler available for building the C/C++ libraries
during stage 2! Of course, the compiler built during stage 2, cc-lfs, during stage 2. Of course, the compiler built by stage 2, cc-lfs,
would be able to build those libraries, but (1) the build system of would be able to build those libraries, but:</para>
gcc does not know that it is usable on pc, and (2) using it on pc
would create a risk of linking to the pc libraries, since cc-lfs is a native
compiler. So we have to re-build libstdc++ later as a part of
gcc stage 2.</para>
<para>In &ch-final; (or <quote>stage 3</quote>), all packages needed for <itemizedlist>
the LFS system are built. Even if a package is already installed into <listitem>
the LFS system in a previous chapter, we still rebuild the package <para>
unless we are completely sure it's unnecessary. The main reason for Generally cc-lfs cannot run on pc (the host distro). Despite the
rebuilding these packages is to settle them down: if we reinstall a LFS 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
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
a risk of linking to the pc libraries, since cc-lfs is a native
compiler.
</para>
</listitem>
</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>
<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 package on a complete LFS system, the installed content of the package
should be same as the content of the same package installed in should be the same as the content of the same package when installed in
&ch-final;. The temporary packages installed in &ch-tmp-cross; or &ch-final;. The temporary packages installed in &ch-tmp-cross; or
&ch-tmp-chroot; cannot satisfy this expectation because some of them &ch-tmp-chroot; cannot satisfy this requirement, because some of them
are built without optional dependencies installed, and autoconf cannot are built without optional dependencies, and autoconf cannot
perform some feature checks in &ch-tmp-cross; because of cross perform some feature checks in &ch-tmp-cross; because of cross-compilation,
compilation, causing the temporary packages to lack optional features causing the temporary packages to lack optional features,
or use suboptimal code routines. Additionally, a minor reason for or use suboptimal code routines. Additionally, a minor reason for
rebuilding the packages is allowing to run the testsuite.</para> rebuilding the packages is to run the test suites.</para>
</sect2> </sect2>
<sect2 id="other-details"> <sect2 id="other-details">
<title>Other procedural details</title> <title>Other Procedural Details</title>
<para>The cross-compiler will be installed in a separate <filename <para>The cross-compiler will be installed in a separate <filename
class="directory">$LFS/tools</filename> directory, since it will not class="directory">$LFS/tools</filename> directory, since it will not
@ -300,11 +323,11 @@
its library search order. Detailed information can be obtained from its library search order. Detailed information can be obtained from
<command>ld</command> by passing it the <parameter>--verbose</parameter> <command>ld</command> by passing it the <parameter>--verbose</parameter>
flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command> flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command>
will illustrate the current search paths and their order. Note that this will illustrate the current search paths and their order. (Note that this
example can be run as shown only while being user example can be run as shown only while logged in as user
<systemitem class="username">lfs</systemitem>. If you come back to this <systemitem class="username">lfs</systemitem>. If you come back to this
page later, replace <command>$LFS_TGT-ld</command> with just page later, replace <command>$LFS_TGT-ld</command> with
<command>ld</command>.</para> <command>ld</command>).</para>
<para>The next package installed is gcc. An example of what can be <para>The next package installed is gcc. An example of what can be
seen during its run of <command>configure</command> is:</para> seen during its run of <command>configure</command> is:</para>
@ -317,28 +340,28 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
directories to find which tools to use. However, during the actual directories to find which tools to use. However, during the actual
operation of <command>gcc</command> itself, the same search paths are not operation of <command>gcc</command> itself, the same search paths are not
necessarily used. To find out which standard linker <command>gcc</command> necessarily used. To find out which standard linker <command>gcc</command>
will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. Again, will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>. (Again,
remove the <command>$LFS_TGT-</command> part if coming back to this remove the <command>$LFS_TGT-</command> prefix if coming back to this
later.</para> later.)</para>
<para>Detailed information can be obtained from <command>gcc</command> by <para>Detailed information can be obtained from <command>gcc</command> by
passing it the <parameter>-v</parameter> command line option while compiling passing it the <parameter>-v</parameter> command line option while compiling
a program. For example, <command>$LFS_TGT-gcc -v a program. For example, <command>$LFS_TGT-gcc -v
<replaceable>example.c</replaceable></command> (or without <command> <replaceable>example.c</replaceable></command> (or without <command>
$LFS_TGT-</command> if coming back later to this) will show $LFS_TGT-</command> if coming back later) will show
detailed information about the preprocessor, compilation, and assembly detailed information about the preprocessor, compilation, and assembly
stages, including <command>gcc</command>'s search paths for included stages, including <command>gcc</command>'s search paths for included
headers and their order.</para> headers and their order.</para>
<para>Next installed are sanitized Linux API headers. These allow the <para>Next up: sanitized Linux API headers. These allow the
standard C library (glibc) to interface with features that the Linux standard C library (glibc) to interface with features that the Linux
kernel will provide.</para> kernel will provide.</para>
<para>The next package installed is glibc. The most important <para>Next comes glibc. The most important
considerations for building glibc are the compiler, binary tools, and considerations for building glibc are the compiler, binary tools, and
kernel headers. The compiler is generally not an issue since glibc will kernel headers. The compiler is generally not an issue since glibc will
always use the compiler relating to the <parameter>--host</parameter> always use the compiler relating to the <parameter>--host</parameter>
parameter passed to its configure script; e.g. in our case, the compiler parameter passed to its configure script; e.g., in our case, the compiler
will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel
headers can be a bit more complicated. Therefore, we take no risks and use headers can be a bit more complicated. Therefore, we take no risks and use
the available configure switches to enforce the correct selections. After the available configure switches to enforce the correct selections. After
@ -350,12 +373,12 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
and the use of the <parameter>-nostdinc</parameter> and and the use of the <parameter>-nostdinc</parameter> and
<parameter>-isystem</parameter> flags to control the compiler's include <parameter>-isystem</parameter> flags to control the compiler's include
search path. These items highlight an important aspect of the glibc search path. These items highlight an important aspect of the glibc
package&mdash;it is very self-sufficient in terms of its build machinery package&mdash;it is very self-sufficient in terms of its build machinery,
and generally does not rely on toolchain defaults.</para> and generally does not rely on toolchain defaults.</para>
<para>As mentioned above, the standard C++ library is compiled next, followed in <para>As mentioned above, the standard C++ library is compiled next, followed in
<xref linkend="chapter-temporary-tools"/> by other programs that need <xref linkend="chapter-temporary-tools"/> by other programs that must
to be cross compiled for breaking circular dependencies at build time. be cross-compiled to break circular dependencies at build time.
The install step of all those packages uses the The install step of all those packages uses the
<envar>DESTDIR</envar> variable to force installation <envar>DESTDIR</envar> variable to force installation
in the LFS filesystem.</para> in the LFS filesystem.</para>
@ -377,7 +400,7 @@ checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</compute
operation of the toolchain are performed. From this point onwards, the operation of the toolchain are performed. From this point onwards, the
core toolchain is self-contained and self-hosted. In core toolchain is self-contained and self-hosted. In
<xref linkend="chapter-building-system"/>, final versions of all the <xref linkend="chapter-building-system"/>, final versions of all the
packages needed for a fully functional system are built, tested and packages needed for a fully functional system are built, tested, and
installed.</para> installed.</para>
</sect2> </sect2>

12
prologue/errata.xml
View File

@ -21,10 +21,12 @@
build the LFS system.</para> build the LFS system.</para>
<para>In addition, the Linux From Scratch editors maintain a list of security <para>In addition, the Linux From Scratch editors maintain a list of security
vulnerabilities discovered <emphasis>after</emphasis> a book has been released. To see vulnerabilities discovered <emphasis>after</emphasis> a book has been released. To read the list, please visit
whether there are any known security vulnerabilities, please visit <ulink url="&secadv;"/> before proceeding with your build. You should apply
<ulink url="&secadv;"/> before proceeding with your build. You should also continue the changes suggested by the advisories to the relevant sections of the
to consult the advisories, and fix any security vulnerabilities, even book as you build the LFS system. And, if you will use the LFS system as
when the LFS system has been completely constructed.</para> a real desktop or server system, you should continue to consult the
advisories and fix any security vulnerabilities, even when the LFS system
has been completely constructed.</para>
</sect1> </sect1>