Changeset 6dfcfecc for chapter04

Timestamp:

03/31/2021 10:41:39 AM (3 years ago)

Author:

Xℹ Ruoyao <xry111@…>

Branches:

ml-11.0, multilib

Children:

7610848

Parents:

811b5a39

git-author:

Thomas Trepl <thomas@…> (06/29/2020 07:55:01 AM)

git-committer:

Xℹ Ruoyao <xry111@…> (03/31/2021 10:41:39 AM)

Message:

Update to new lfs structure

git-svn-id: ​http://svn.linuxfromscratch.org/LFS/branches/multilib@11986 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

Location:

chapter04

Files:

• aboutlfs.xml (deleted)
• aboutsbus.xml (modified) (3 diffs)
• abouttestsuites.xml (modified) (1 diff)
• addinguser.xml (modified) (4 diffs)
• chapter04.xml (modified) (1 diff)
• creatingminlayout.xml (added)
• creatingtoolsdir.xml (deleted)
• introduction.xml (modified) (1 diff)
• settingenviron.xml (modified) (4 diffs)

chapter04/aboutsbus.xml

@@ -21 +21 @@
 
   <para>The SBU measure works as follows. The first package to be compiled
-  from this book is Binutils in <xref linkend="chapter-temporary-tools"/>. The
+  from this book is binutils in <xref linkend="chapter-cross-tools"/>. The
   time it takes to compile this package is what will be referred to as the
   Standard Build Unit or SBU. All other compile times will be expressed relative
@@ -28 +28 @@
   <para>For example, consider a package whose compilation time is 4.5
   SBUs. This means that if a system took 10 minutes to compile and
-  install the first pass of Binutils, it will take
+  install the first pass of binutils, it will take
   <emphasis>approximately</emphasis> 45 minutes to build this example package.
-  Fortunately, most build times are shorter than the one for Binutils.</para>
+  Fortunately, most build times are shorter than the one for binutils.</para>
 
   <para>In general, SBUs are not entirely accurate because they depend on many
@@ -42 +42 @@
     make" by either setting an environment variable or telling the
     <command>make</command> program how many processors are available.  For
-    instance, a Core2Duo can support two simultaneous processes with:</para>
+    instance, an Intel i5-6500 CPU can support four simultaneous processes with:</para>
 
-    <screen role="nodump"><userinput>export MAKEFLAGS='-j 2'</userinput></screen>
+    <screen role="nodump"><userinput>export MAKEFLAGS='-j4'</userinput></screen>
 
     <para>or just building with:</para>
 
-    <screen role="nodump"><userinput>make -j2</userinput></screen>
+    <screen role="nodump"><userinput>make -j4</userinput></screen>
 
     <para>When multiple processors are used in this way, the SBU units in the

chapter04/abouttestsuites.xml

@@ -19 +19 @@
 
   <para>Some test suites are more important than others. For example,
-  the test suites for the core toolchain packages&mdash;GCC, Binutils, and
-  Glibc&mdash;are of the utmost importance due to their central role in a
-  properly functioning system. The test suites for GCC and Glibc can
+  the test suites for the core toolchain packages&mdash;GCC, binutils, and
+  glibc&mdash;are of the utmost importance due to their central role in a
+  properly functioning system. The test suites for GCC and glibc can
   take a very long time to complete, especially on slower hardware, but
   are strongly recommended.</para>
 
   <note>
-    <para>Experience has shown that there is little to be gained from running
-    the test suites in <xref linkend="chapter-temporary-tools"/>. There can be
-    no escaping the fact that the host system always exerts some influence on
-    the tests in that chapter, often causing inexplicable failures. Because
-    the tools built in <xref linkend="chapter-temporary-tools"/> are temporary
-    and eventually discarded, we do not recommend running the test suites in
-    <xref linkend="chapter-temporary-tools"/> for the average reader. The
-    instructions for running those test suites are provided for the benefit of
-    testers and developers, but they are strictly optional.</para>
+    <para>Running the test suites in <xref linkend="chapter-cross-tools"/>
+    and <xref linkend="chapter-temporary-tools"/>
+    is impossible, since the programs are compiled with a cross-compiler,
+    so are not supposed to be able to run on the build host.</para>
   </note>
 
-  <para>A common issue with running the test suites for Binutils and GCC
+  <para>A common issue with running the test suites for binutils and GCC
   is running out of pseudo terminals (PTYs). This can result in a high
   number of failing tests. This may happen for several reasons, but the

chapter04/addinguser.xml

@@ -12 +12 @@
 
   <para>When logged in as user <systemitem class="username">root</systemitem>,
-  making a single mistake can damage or destroy a system. Therefore, we
-  recommend building the packages in the next chapter as an unprivileged user.
+  making a single mistake can damage or destroy a system. Therefore, 
+  the packages in the next two chapters are built as an unprivileged user.
   You could use your own user name, but to make it easier to set up a clean
   working environment, create a new user called <systemitem
@@ -63 +63 @@
       <term><parameter>lfs</parameter></term>
       <listitem>
-        <para>This is the actual name for the created group and user.</para>
+        <para>This is the actual name for the created user.</para>
       </listitem>
     </varlistentry>
@@ -78 +78 @@
 
   <para>Grant <systemitem class="username">lfs</systemitem> full access to
-  <filename class="directory">$LFS/tools</filename> by making
+  all directories under <filename class="directory">$LFS</filename> by making
   <systemitem class="username">lfs</systemitem> the directory owner:</para>
 
-<screen><userinput>chown -v lfs $LFS/tools</userinput></screen>
+<screen><userinput>chown -v lfs $LFS/{usr,lib,var,etc,bin,sbin,tools}
+case $(uname -m) in
+  x86_64) chown -v lfs $LFS/lib64 ;;
+esac</userinput></screen>
+<screen arch="ml_32"  ><userinput>chown -v lfs $LFS&lib-m32;</userinput></screen>
+<screen arch="ml_x32" ><userinput>chown -v lfs $LFS&lib-mx32;</userinput></screen>
+<screen arch="ml_all" ><userinput>chown -v lfs $LFS/{lib32,libx32}</userinput></screen>
 
   <para>If a separate working directory was created as suggested, give
@@ -96 +102 @@
   <para>Next, login as user <systemitem class="username">lfs</systemitem>.
   This can be done via a virtual console, through a display manager, or with
-  the following substitute user command:</para>
+  the following substitute/switch user command:</para>
 
 <screen role="nodump"><userinput>su - lfs</userinput></screen>

chapter04/chapter04.xml

@@ -14 +14 @@
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="introduction.xml"/>
   <!--<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="aboutlfs.xml"/>-->
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="creatingtoolsdir.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="creatingminlayout.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="addinguser.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="settingenviron.xml"/>

chapter04/introduction.xml

@@ -12 +12 @@
 
   <para>In this chapter, we will perform a few additional tasks to prepare
-  for building the temporary system. We will create a directory in
+  for building the temporary system. We will create a set of directories in
   <filename class="directory">$LFS</filename> for the installation of the
   temporary tools, add an unprivileged user to reduce risk,

chapter04/settingenviron.xml

@@ -44 +44 @@
 LC_ALL=POSIX
 LFS_TGT=$(uname -m)-lfs-linux-gnu
-PATH=/tools/bin:/bin:/usr/bin
+PATH=/usr/bin
+if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
+PATH=$LFS/tools/bin:$PATH
 export LFS LC_ALL LFS_TGT PATH</literal>
 EOF</userinput></screen>
@@ -55 +57 @@
 LFS_TGT32=i686-lfs-linux-gnu
 LFS_TGTX32=x86_64-lfs-linux-gnux32
-PATH=/tools/bin:/bin:/usr/bin
+PATH=/usr/bin
+if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
+PATH=$LFS/tools/bin:$PATH
 export LFS LC_ALL LFS_TGT LFS_TGT32 LFS_TGTX32 PATH</literal>
 EOF</userinput></screen>
 
   <variablelist>
-    <title>The meaning of the command line options in <filename>.bashrc</filename></title>
+    <title>The meaning of the settings in <filename>.bashrc</filename></title>
 
     <varlistentry>
@@ -120 +124 @@
 
     <varlistentry>
-      <term><parameter>PATH=/tools/bin:/bin:/usr/bin</parameter></term>
-      <listitem>
-  <para>By putting <filename class="directory">/tools/bin</filename> ahead of the
-  standard <envar>PATH</envar>, all the programs installed in <xref
-  linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
-  their installation. This, combined with turning off hashing, limits the risk
-  that old programs are used from the host when the same programs are available in
-  the Chapter 5 environment.</para>
+      <term><parameter>PATH=/usr/bin</parameter></term>
+      <listitem>
+  <para>Many modern linux distributions have merged <filename
+  class="directory">/bin</filename> and <filename
+  class="directory">/usr/bin</filename>. When this is the case, the standard
+  <envar>PATH</envar> variable needs just to be set to <filename
+  class="directory">/usr/bin/</filename> for the <xref
+  linkend="chapter-temporary-tools"/> environment. When this is not the
+  case, the following line adds <filename class="directory">/bin</filename>
+  to the path.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>if [ ! -L /bin ]; then PATH=/bin:$PATH; fi</parameter></term>
+      <listitem>
+  <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>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>PATH=$LFS/tools/bin:$PATH</parameter></term>
+      <listitem>
+  <para>By putting <filename class="directory">$LFS/tools/bin</filename> ahead of the
+  standard <envar>PATH</envar>, the cross-compiler installed at the beginning
+  of <xref linkend="chapter-cross-tools"/> is picked up by the shell
+  immediately after its installation. This, combined with turning off hashing,
+  limits the risk that the compiler from the host be used instead of the
+  cross-compiler.</para>
       </listitem>
     </varlistentry>
@@ -135 +161 @@
       <listitem>
         <para>While the above 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>
     </varlistentry>
 
   </variablelist>
+
+  <important>
+
+     <para>Several commercial distributions add a non-documented instantiation
+     of <filename>/etc/bash.bashrc</filename> to the initialization of
+     <command>bash</command>. This file has the potential to modify the
+     <systemitem class="username">lfs</systemitem>
+     user's environment in ways that can affect the building of critical LFS
+     packages. To make sure the <systemitem class="username">lfs</systemitem>
+     user's envronment is clean, check for the
+     presence of <filename>/etc/bash.bashrc</filename> and, if present, move it
+     out of the way.  As the <systemitem class="username">root</systemitem>
+     user, run:</para>
+
+     <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>
+     user is finished at the beginning of <xref
+     linkend="chapter-chroot-temporary-tools"/>, you can restore
+         <filename>/etc/bash.bashrc</filename> (if desired).</para>
+
+     <para>Note that the LFS Bash package we will build in
+     <xref linkend="ch-system-bash"/> is not configured to load or execute
+     <filename>/etc/bash.bashrc</filename>, so this file is useless on a
+     completed LFS system.</para>
+  </important>
 
   <para>Finally, to have the environment fully prepared for building the