Split Chapter 5 into three separate chapters.

Implement a new method of cross-building the LFS tool chain
and other tools to simplify the method of isolating the 
new system from the original host.  This will be the start of
LFS-10.0.

Move old trunk/BOOK to branches/old-trunk.



git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@11946 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

7 files changed, 95 insertions, 38 deletions

diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml
index 68e25cce2..1928423ea 100644
--- a/chapter04/aboutsbus.xml
+++ b/chapter04/aboutsbus.xml
@@ -20,16 +20,16 @@
   used instead.</para>
 
   <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
   to this time.</para>
 
   <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
   factors, including the host system's version of GCC.  They are provided here
@@ -41,13 +41,13 @@
     compilation time for a package can be reduced by performing a "parallel
     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
     book will vary even more than they normally would.  In some cases, the make
diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml
index 1b2e0d68f..9206f33be 100644
--- a/chapter04/abouttestsuites.xml
+++ b/chapter04/abouttestsuites.xml
@@ -18,25 +18,20 @@
   that the package is totally bug free.</para>
 
   <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
   most likely cause is that the host system does not have the
diff --git a/chapter04/addinguser.xml b/chapter04/addinguser.xml
index a26aa55a2..6a163f46b 100644
--- a/chapter04/addinguser.xml
+++ b/chapter04/addinguser.xml
@@ -11,8 +11,8 @@
   <title>Adding the LFS User</title>
 
   <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
   class="username">lfs</systemitem> as a member of a new group (also named
@@ -62,7 +62,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
     <varlistentry>
       <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>
 
@@ -77,10 +77,13 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
 <screen role="nodump"><userinput>passwd lfs</userinput></screen>
 
   <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>
 
   <para>If a separate working directory was created as suggested, give
   user <systemitem class="username">lfs</systemitem> ownership of this
@@ -95,7 +98,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
 
   <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>
 
diff --git a/chapter04/chapter04.xml b/chapter04/chapter04.xml
index 3e44ce94f..5ad2d22db 100644
--- a/chapter04/chapter04.xml
+++ b/chapter04/chapter04.xml
@@ -13,7 +13,7 @@
 
   <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"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="aboutsbus.xml"/>
diff --git a/chapter04/creatingminlayout.xml b/chapter04/creatingminlayout.xml
new file mode 100644
index 000000000..731d21c54
--- /dev/null
+++ b/chapter04/creatingminlayout.xml
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+  <!ENTITY % general-entities SYSTEM "../general.ent">
+  %general-entities;
+]>
+
+<sect1 id="ch-tools-creatingminlayout">
+  <?dbhtml filename="creatingminlayout.html"?>
+
+  <title>Creating the Minimal directory layout in LFS filesystem</title>
+
+  <para>The first task performed in the LFS partition is to create a minimal
+  directory hierarchy so that programs compiled in <xref
+  linkend="chapter-temporary-tools"/> may be installed in their final
+  location. This is needed so that those temporary programs be overwritten
+  when rebuilding them in <xref linkend="chapter-building-system"/>.</para>
+
+  <para>Create the required directory layout by running the following as
+  <systemitem class="username">root</systemitem>:</para>
+
+<screen><userinput>mkdir -pv $LFS/{usr,lib,var,etc,bin,sbin}
+case $(uname -m) in
+  x86_64) mkdir -pv $LFS/lib64 ;;
+esac</userinput></screen>
+
+  <para>Programs in <xref linkend="chapter-temporary-tools"/> will be compiled
+  with a cross-compiler (more details in section <xref
+  linkend="ch-tools-toolchaintechnotes"/>). In order to separate this
+  cross-compiler from the other programs, it will be installed in a special
+  directory. Create this directory with:</para>
+
+<screen><userinput>mkdir -pv $LFS/tools</userinput></screen>
+
+</sect1>
diff --git a/chapter04/introduction.xml b/chapter04/introduction.xml
index f1ac91989..c54c67f8c 100644
--- a/chapter04/introduction.xml
+++ b/chapter04/introduction.xml
@@ -11,7 +11,7 @@
   <title>Introduction</title>
 
   <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,
   and create an appropriate build environment for that user. We will also
diff --git a/chapter04/settingenviron.xml b/chapter04/settingenviron.xml
index 512d30d10..9c8bae7a9 100644
--- a/chapter04/settingenviron.xml
+++ b/chapter04/settingenviron.xml
@@ -43,12 +43,14 @@ umask 022
 LFS=/mnt/lfs
 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>
 
   <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>
       <term><parameter>set +h</parameter></term>
@@ -61,7 +63,7 @@ EOF</userinput></screen>
   be used as soon as they are installed. By switching off the hash function,
   the shell will always search the <envar>PATH</envar> when a program is to
   be run. As such, the shell will find the newly compiled tools in
-  <filename class="directory">$LFS/tools</filename> as soon as they are
+  <filename class="directory">~/tools</filename> as soon as they are
   available without remembering a previous version of the same program in a
   different location.</para>
       </listitem>
@@ -108,14 +110,36 @@ EOF</userinput></screen>
     </varlistentry>
 
     <varlistentry>
-      <term><parameter>PATH=/tools/bin:/bin:/usr/bin</parameter></term>
+      <term><parameter>PATH=/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>
+  <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>
 
@@ -123,7 +147,7 @@ EOF</userinput></screen>
       <term><parameter>export LFS LC_ALL LFS_TGT PATH</parameter></term>
       <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>