Changeset 6a3b6af


Ignore:
Timestamp:
01/15/2006 12:10:43 PM (18 years ago)
Author:
Manuel Canales Esparcia <manuel@…>
Branches:
10.0, 10.0-rc1, 10.1, 10.1-rc1, 11.0, 11.0-rc1, 11.0-rc2, 11.0-rc3, 11.1, 11.1-rc1, 11.2, 11.2-rc1, 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.5-systemd, 7.6, 7.6-systemd, 7.7, 7.7-systemd, 7.8, 7.8-systemd, 7.9, 7.9-systemd, 8.0, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, arm, bdubbs/gcc13, ml-11.0, multilib, renodr/libudev-from-systemd, s6-init, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/lfs-next, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
Children:
3467c02f
Parents:
b0ed1af
Message:

Indented chapter 04.

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

Location:
chapter04
Files:
7 edited

Legend:

Unmodified
Added
Removed

  • chapter04/aboutlfs.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="prepare-aboutlfs">
    7 <title>About $LFS</title>
    8 <?dbhtml filename="aboutlfs.html"?>
     9  <?dbhtml filename="aboutlfs.html"?>
    910
    10 <para>Throughout this book, the environment variable <envar>LFS</envar> will
    11 be used several times. It is paramount that this variable is always defined.
    12 It should be set to the mount point chosen for the LFS partition.
    13 Check that the <envar>LFS</envar> variable is set up properly with:</para>
     11  <title>About $LFS</title>
     12
     13  <para>Throughout this book, the environment variable <envar>LFS</envar> will
     14  be used several times. It is paramount that this variable is always defined.
     15  It should be set to the mount point chosen for the LFS partition.
     16  Check that the <envar>LFS</envar> variable is set up properly with:</para>
    1417
    1518<screen role="nodump"><userinput>echo $LFS</userinput></screen>
    1619
    17 <para>Make sure the output shows the path to the LFS partition's mount
    18 point, which is <filename class="directory">/mnt/lfs</filename> if the
    19 provided example was followed. If the output is incorrect, the
    20 variable can be set with:</para>
     20  <para>Make sure the output shows the path to the LFS partition's mount
     21  point, which is <filename class="directory">/mnt/lfs</filename> if the
     22  provided example was followed. If the output is incorrect, the
     23  variable can be set with:</para>
    2124
    2225<screen role="nodump"><userinput>export LFS=/mnt/lfs</userinput></screen>
    2326
    24 <para>Having this variable set is beneficial in that commands such as
    25 <command>mkdir $LFS/tools</command> can be typed literally. The shell
    26 will automatically replace <quote>$LFS</quote> with
    27 <quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
    28 processes the command line.</para>
     27  <para>Having this variable set is beneficial in that commands such as
     28  <command>mkdir $LFS/tools</command> can be typed literally. The shell
     29  will automatically replace <quote>$LFS</quote> with
     30  <quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
     31  processes the command line.</para>
    2932
    30 <para>Do not forget to check that <envar>$LFS</envar> is set whenever
    31 you leave and reenter the current working environment (as when doing a
    32 <quote>su</quote> to <emphasis>root</emphasis> or another user).</para>
     33  <para>Do not forget to check that <envar>$LFS</envar> is set whenever
     34  you leave and reenter the current working environment (as when doing a
     35  <command>su</command> to <systemitem class="username">root</systemitem>
     36  or another user).</para>
    3337
    3438</sect1>

  • chapter04/aboutsbus.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="prepare-aboutsbus">
    7 <title>About SBUs</title>
    8 <?dbhtml filename="aboutsbus.html"?>
     9  <?dbhtml filename="aboutsbus.html"?>
    910
    10 <para>Many people would like to know beforehand approximately how long
    11 it takes to compile and install each package. Because Linux From
    12 Scratch can be built on many different systems, it is impossible to
    13 provide accurate time estimates.  The biggest package (Glibc) will
    14 take approximately 20 minutes on the fastest systems, but could take
    15 up to three days on slower systems! Instead of providing actual times,
    16 the Standard Build Unit (SBU) measure will be
    17 used instead.</para>
     11  <title>About SBUs</title>
    1812
    19 <para>The SBU measure works as follows. The first package to be compiled
    20 from this book is Binutils in <xref linkend="chapter-temporary-tools"/>.  The
    21 time it takes to compile this package is what will be referred to as the
    22 Standard Build Unit or SBU. All other compile times will be expressed relative
    23 to this time.</para>
     13  <para>Many people would like to know beforehand approximately how long
     14  it takes to compile and install each package. Because Linux From
     15  Scratch can be built on many different systems, it is impossible to
     16  provide accurate time estimates. The biggest package (Glibc) will
     17  take approximately 20 minutes on the fastest systems, but could take
     18  up to three days on slower systems! Instead of providing actual times,
     19  the Standard Build Unit (SBU) measure will be
     20  used instead.</para>
    2421
    25 <para>For example, consider a package whose compilation time is 4.5
    26 SBUs. This means that if a system took 10 minutes to compile and
    27 install the first pass of Binutils, it will take
    28 <emphasis>approximately</emphasis> 45 minutes to build this example package.
    29 Fortunately, most build times are shorter than the one for Binutils.</para>
     22  <para>The SBU measure works as follows. The first package to be compiled
     23  from this book is Binutils in <xref linkend="chapter-temporary-tools"/>. The
     24  time it takes to compile this package is what will be referred to as the
     25  Standard Build Unit or SBU. All other compile times will be expressed relative
     26  to this time.</para>
    3027
    31 <para>In general, SBUs are not entirely accurate because they depend on many
    32 factors, including the host system's version of GCC. Note that on Symmetric
    33 Multi-Processor (SMP)-based machines, SBUs are even less accurate.  They are
    34 provided here to give an estimate of how long it might take to install a
    35 package, but the numbers can vary by as much as dozens of minutes in some
    36 cases.</para>
     28  <para>For example, consider a package whose compilation time is 4.5
     29  SBUs. This means that if a system took 10 minutes to compile and
     30  install the first pass of Binutils, it will take
     31  <emphasis>approximately</emphasis> 45 minutes to build this example package.
     32  Fortunately, most build times are shorter than the one for Binutils.</para>
    3733
    38 <para>To view actual timings for a number of specific machines, we recommend
    39 The LinuxFromScratch SBU Home Page at <ulink url="&lfs-root;~bdubbs/"/>.</para>
     34  <para>In general, SBUs are not entirely accurate because they depend on many
     35  factors, including the host system's version of GCC. Note that on Symmetric
     36  Multi-Processor (SMP)-based machines, SBUs are even less accurate. They are
     37  provided here to give an estimate of how long it might take to install a
     38  package, but the numbers can vary by as much as dozens of minutes in some
     39  cases.</para>
     40
     41  <para>To view actual timings for a number of specific machines, we recommend
     42  The LinuxFromScratch SBU Home Page at <ulink url="&lfs-root;~bdubbs/"/>.</para>
    4043
    4144</sect1>

  • chapter04/abouttestsuites.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="prepare-abouttestsuites">
    7 <title>About the Test Suites</title>
    8 <?dbhtml filename="abouttestsuites.html"?>
     9  <?dbhtml filename="abouttestsuites.html"?>
    910
    10 <para>Most packages provide a test suite. Running the test suite for a
    11 newly built package is a good idea because it can provide a <quote>sanity
    12 check</quote> indicating that everything compiled correctly. A test suite
    13 that passes its set of checks usually proves that the package is
    14 functioning as the developer intended. It does not, however, guarantee
    15 that the package is totally bug free.</para>
     11  <title>About the Test Suites</title>
    1612
    17 <para>Some test suites are more important than others. For example,
    18 the test suites for the core toolchain packages&mdash;GCC, Binutils, and
    19 Glibc&mdash;are of the utmost importance due to their central role in a
    20 properly functioning system. The test suites for GCC and Glibc can
    21 take a very long time to complete, especially on slower hardware, but
    22 are strongly recommended.</para>
     13  <para>Most packages provide a test suite. Running the test suite for a
     14  newly built package is a good idea because it can provide a <quote>sanity
     15  check</quote> indicating that everything compiled correctly. A test suite
     16  that passes its set of checks usually proves that the package is
     17  functioning as the developer intended. It does not, however, guarantee
     18  that the package is totally bug free.</para>
    2319
    24 <note><para>Experience has shown that there is little to be gained
    25 from running the test suites in <xref
    26 linkend="chapter-temporary-tools"/>. There can be no escaping the fact
    27 that the host system always exerts some influence on the tests in that
    28 chapter, often causing inexplicable failures. Because the tools built
    29 in <xref linkend="chapter-temporary-tools"/> are temporary and
    30 eventually discarded, we do not recommend running the test suites in
    31 <xref linkend="chapter-temporary-tools"/> for the average reader. The
    32 instructions for running those test suites are provided for the
    33 benefit of testers and developers, but they are strictly
    34 optional.</para></note>
     20  <para>Some test suites are more important than others. For example,
     21  the test suites for the core toolchain packages&mdash;GCC, Binutils, and
     22  Glibc&mdash;are of the utmost importance due to their central role in a
     23  properly functioning system. The test suites for GCC and Glibc can
     24  take a very long time to complete, especially on slower hardware, but
     25  are strongly recommended.</para>
    3526
    36 <para>A common issue with running the test suites for Binutils and GCC
    37 is running out of pseudo terminals (PTYs). This can result in a high
    38 number of failing tests. This may happen for several reasons, but the
    39 most likely cause is that the host system does not have the
    40 <systemitem class="filesystem">devpts</systemitem> file system set up
    41 correctly. This issue is discussed in greater detail in <xref
    42 linkend="chapter-temporary-tools"/>.</para>
     27  <note>
     28    <para>Experience has shown that there is little to be gained from running
     29    the test suites in <xref linkend="chapter-temporary-tools"/>. There can be
     30    no escaping the fact that the host system always exerts some influence on
     31    the tests in that chapter, often causing inexplicable failures. Because
     32    the tools built in <xref linkend="chapter-temporary-tools"/> are temporary
     33    and eventually discarded, we do not recommend running the test suites in
     34    <xref linkend="chapter-temporary-tools"/> for the average reader. The
     35    instructions for running those test suites are provided for the benefit of
     36    testers and developers, but they are strictly optional.</para>
     37  </note>
    4338
    44 <para>Sometimes package test suites will fail, but for reasons which the
    45 developers are aware of and have deemed non-critical. Consult the logs located
    46 at <ulink url="&test-results;"/> to verify whether or not these failures are
    47 expected. This site is valid for all tests throughout this book.</para>
     39  <para>A common issue with running the test suites for Binutils and GCC
     40  is running out of pseudo terminals (PTYs). This can result in a high
     41  number of failing tests. This may happen for several reasons, but the
     42  most likely cause is that the host system does not have the
     43  <systemitem class="filesystem">devpts</systemitem> file system set up
     44  correctly. This issue is discussed in greater detail in <xref
     45  linkend="chapter-temporary-tools"/>.</para>
     46
     47  <para>Sometimes package test suites will fail, but for reasons which the
     48  developers are aware of and have deemed non-critical. Consult the logs located
     49  at <ulink url="&test-results;"/> to verify whether or not these failures are
     50  expected. This site is valid for all tests throughout this book.</para>
    4851
    4952</sect1>
    50 

  • chapter04/addinguser.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="ch-tools-addinguser">
    7 <title>Adding the LFS User</title>
    8 <?dbhtml filename="addinguser.html"?>
     9  <?dbhtml filename="addinguser.html"?>
    910
    10 <para>When logged in as user <emphasis>root</emphasis>, making a single mistake
    11 can damage or destroy a system. Therefore, we recommend building the packages in
    12 this chapter as an unprivileged user. You could use your own user name, but to
    13 make it easier to set up a clean working environment, create a new user called
    14 <emphasis>lfs</emphasis> as a member of a new group (also named
    15 <emphasis>lfs</emphasis>) and use this user during the installation process. As
    16 <emphasis>root</emphasis>, issue the following commands to add the new
    17 user:</para>
     11  <title>Adding the LFS User</title>
     12
     13  <para>When logged in as user <systemitem class="username">root</systemitem>,
     14  making a single mistake can damage or destroy a system. Therefore, we
     15  recommend building the packages in this chapter as an unprivileged user.
     16  You could use your own user name, but to make it easier to set up a clean
     17  working environment, create a new user called <systemitem
     18  class="username">lfs</systemitem> as a member of a new group (also named
     19  <systemitem class="groupname">lfs</systemitem>) and use this user during
     20  the installation process. As <systemitem class="username">root</systemitem>,
     21  issue the following commands to add the new user:</para>
    1822
    1923<screen><userinput>groupadd lfs
    2024useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
    2125
    22 <para>The meaning of the command line options:</para>
     26  <variablelist>
     27    <title>The meaning of the command line options:</title>
    2328
    24 <variablelist>
    25 <varlistentry>
    26 <term><parameter>-s /bin/bash</parameter></term>
    27 <listitem><para>This makes
    28 <command>bash</command> the default shell for user
    29 <emphasis>lfs</emphasis>.</para></listitem>
    30 </varlistentry>
     29    <varlistentry>
     30      <term><parameter>-s /bin/bash</parameter></term>
     31      <listitem>
     32        <para>This makes <command>bash</command> the default shell for user
     33        <systemitem class="username">lfs</systemitem>.</para>
     34      </listitem>
     35    </varlistentry>
    3136
    32 <varlistentry>
    33 <term><parameter>-g lfs</parameter></term>
    34 <listitem><para>This option adds user <emphasis>lfs</emphasis> to group
    35 <emphasis>lfs</emphasis>.</para></listitem>
    36 </varlistentry>
     37    <varlistentry>
     38      <term><parameter>-g lfs</parameter></term>
     39      <listitem>
     40        <para>This option adds user <systemitem class="username">lfs</systemitem>
     41        to group <systemitem class="groupname">lfs</systemitem>.</para>
     42      </listitem>
     43    </varlistentry>
    3744
    38 <varlistentry>
    39 <term><parameter>-m</parameter></term>
    40 <listitem><para>This creates a home
    41 directory for <emphasis>lfs</emphasis>.</para></listitem>
    42 </varlistentry>
     45    <varlistentry>
     46      <term><parameter>-m</parameter></term>
     47      <listitem>
     48        <para>This creates a home directory for <systemitem
     49        class="username">lfs</systemitem>.</para>
     50      </listitem>
     51    </varlistentry>
    4352
    44 <varlistentry>
    45 <term><parameter>-k /dev/null</parameter></term>
    46 <listitem><para>This parameter
    47 prevents possible copying of files from a skeleton directory (default
    48 is <filename class="directory">/etc/skel</filename>) by changing the input location to
    49 the special null device.</para></listitem>
    50 </varlistentry>
     53    <varlistentry>
     54      <term><parameter>-k /dev/null</parameter></term>
     55      <listitem>
     56        <para>This parameter prevents possible copying of files from a skeleton
     57        directory (default is <filename class="directory">/etc/skel</filename>)
     58        by changing the input location to the special null device.</para>
     59      </listitem>
     60    </varlistentry>
    5161
    52 <varlistentry>
    53 <term><parameter>lfs</parameter></term>
    54 <listitem><para>This is the actual name for the created group and
    55 user.</para></listitem>
    56 </varlistentry>
    57 </variablelist>
     62    <varlistentry>
     63      <term><parameter>lfs</parameter></term>
     64      <listitem>
     65        <para>This is the actual name for the created group and user.</para>
     66      </listitem>
     67    </varlistentry>
    5868
    59 <para>To log in as <emphasis>lfs</emphasis> (as opposed to switching
    60 to user <emphasis>lfs</emphasis> when
    61 logged in as <emphasis>root</emphasis>, which does not require the
    62 <emphasis>lfs</emphasis> user to have a
    63 password), give <emphasis>lfs</emphasis> a password:</para>
     69  </variablelist>
     70
     71  <para>To log in as <systemitem class="username">lfs</systemitem> (as opposed
     72  to switching to user <systemitem class="username">lfs</systemitem> when logged
     73  in as <systemitem class="username">root</systemitem>, which does not require
     74  the <systemitem class="username">lfs</systemitem> user to have a password),
     75  give <systemitem class="username">lfs</systemitem> a password:</para>
    6476
    6577<screen role="nodump"><userinput>passwd lfs</userinput></screen>
    6678
    67 <para>Grant <emphasis>lfs</emphasis> full access to
    68 <filename class="directory">$LFS/tools</filename> by making
    69 <emphasis>lfs</emphasis> the directory owner:</para>
     79  <para>Grant <systemitem class="username">lfs</systemitem> full access to
     80  <filename class="directory">$LFS/tools</filename> by making
     81  <systemitem class="username">lfs</systemitem> the directory owner:</para>
    7082
    7183<screen><userinput>chown -v lfs $LFS/tools</userinput></screen>
    7284
    73 <para>If a separate working directory was created as suggested, give
    74 user <emphasis>lfs</emphasis> ownership of this directory:</para>
     85  <para>If a separate working directory was created as suggested, give
     86  user <systemitem class="username">lfs</systemitem> ownership of this
     87  directory:</para>
    7588
    7689<screen><userinput>chown -v lfs $LFS/sources</userinput></screen>
    7790
    78 <para>Next, login as user <emphasis>lfs</emphasis>. This can be done
    79 via a virtual console, through a display manager, or with the
    80 following substitute user command:</para>
     91  <para>Next, login as user <systemitem class="username">lfs</systemitem>.
     92  This can be done via a virtual console, through a display manager, or with
     93  the following substitute user command:</para>
    8194
    82 <screen><userinput>su - lfs</userinput></screen>
     95<screen role="nodump"><userinput>su - lfs</userinput></screen>
    8396
    84 <para>The <quote><parameter>-</parameter></quote> instructs
    85 <command>su</command> to start a login shell as opposed to a non-login shell.
    86 The difference between these two types of shells can be found in detail in
    87 <filename>bash(1)</filename> and <command>info bash</command>.</para>
     97  <para>The <quote><parameter>-</parameter></quote> instructs
     98  <command>su</command> to start a login shell as opposed to a non-login shell.
     99  The difference between these two types of shells can be found in detail in
     100  <filename>bash(1)</filename> and <command>info bash</command>.</para>
    88101
    89102</sect1>
    90 

  • chapter04/chapter04.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<chapter id="chapter-final-preps" xreflabel="Chapter 4">
    7 <?dbhtml dir="chapter04"?>
    8 <title>Final Preparations</title>
    9 <?dbhtml filename="chapter04.html"?>
     9  <?dbhtml dir="chapter04"?>
     10  <?dbhtml filename="chapter04.html"?>
    1011
    11 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
    12 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
    13 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
    14 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
    15 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
    16 <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
     12  <title>Final Preparations</title>
     13
     14  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
     15  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
     16  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
     17  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
     18  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
     19  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
    1720
    1821</chapter>

  • chapter04/creatingtoolsdir.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="ch-tools-creatingtoolsdir">
    7 <title>Creating the $LFS/tools Directory</title>
    8 <?dbhtml filename="creatingtoolsdir.html"?>
     9  <?dbhtml filename="creatingtoolsdir.html"?>
    910
    10 <para>All programs compiled in <xref
    11 linkend="chapter-temporary-tools"/> will be installed under <filename
    12 class="directory">$LFS/tools</filename> to keep them separate from the
    13 programs compiled in <xref linkend="chapter-building-system"/>. The
    14 programs compiled here are temporary tools and will not be a part of
    15 the final LFS system.  By keeping these programs in a separate
    16 directory, they can easily be discarded later after their use. This
    17 also prevents these programs from ending up in the host production
    18 directories (easy to do by accident in <xref
    19 linkend="chapter-temporary-tools"/>).</para>
     11  <title>Creating the $LFS/tools Directory</title>
    2012
    21 <para>Create the required directory by running the following as
    22 <emphasis>root</emphasis>:</para>
     13  <para>All programs compiled in <xref linkend="chapter-temporary-tools"/>
     14  will be installed under <filename class="directory">$LFS/tools</filename>
     15  to keep them separate from the programs compiled in <xref
     16  linkend="chapter-building-system"/>. The programs compiled here are
     17  temporary tools and will not be a part of the final LFS system. By keeping
     18  these programs in a separate directory, they can easily be discarded later
     19  after their use. This also prevents these programs from ending up in the
     20  host production directories (easy to do by accident in <xref
     21  linkend="chapter-temporary-tools"/>).</para>
     22
     23  <para>Create the required directory by running the following as
     24  <systemitem class="username">root</systemitem>:</para>
    2325
    2426<screen><userinput>mkdir -v $LFS/tools</userinput></screen>
    2527
    26 <para>The next step is to create a <filename class="symlink">/tools</filename>
    27 symlink on the host system. This will point to the newly-created directory on
    28 the LFS partition. Run this command as <emphasis>root</emphasis> as
    29 well:</para>
     28  <para>The next step is to create a <filename class="symlink">/tools</filename>
     29  symlink on the host system. This will point to the newly-created directory on
     30  the LFS partition. Run this command as <systemitem
     31  class="username">root</systemitem> as well:</para>
    3032
    3133<screen><userinput>ln -sv $LFS/tools /</userinput></screen>
    3234
    33 <note><para>The above command is correct. The <command>ln</command> command has
    34 a few syntactic variations, so be sure to check <command>info coreutils ln</command> and
    35 <filename>ln(1)</filename> before reporting what you may think is an
    36 error.</para></note>
     35  <note>
     36    <para>The above command is correct. The <command>ln</command> command
     37    has a few syntactic variations, so be sure to check
     38    <command>info coreutils ln</command> and <filename>ln(1)</filename>
     39    before reporting what you may think is an error.</para>
     40  </note>
    3741
    38 <para>The created symlink enables the toolchain to be compiled so that
    39 it always refers to <filename class="directory">/tools</filename>,
    40 meaning that the compiler, assembler, and linker will work both in
    41 this chapter (when we are still using some tools from the host) and in
    42 the next (when we are <quote>chrooted</quote> to the LFS
    43 partition).</para>
     42  <para>The created symlink enables the toolchain to be compiled so that it
     43  always refers to <filename class="directory">/tools</filename>, meaning
     44  that the compiler, assembler, and linker will work both in this chapter
     45  (when we are still using some tools from the host) and in the next (when
     46  we are <quote>chrooted</quote> to the LFS partition).</para>
    4447
    4548</sect1>
    46 

  • chapter04/settingenviron.xml

    rb0ed1af r6a3b6af  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
     2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     3  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
    34  <!ENTITY % general-entities SYSTEM "../general.ent">
    45  %general-entities;
    56]>
     7
    68<sect1 id="ch-tools-settingenviron">
    7 <title>Setting Up the Environment</title>
    8 <?dbhtml filename="settingenvironment.html"?>
     9  <?dbhtml filename="settingenvironment.html"?>
    910
    10 <para>Set up a good working environment by creating two new startup
    11 files for the <command>bash</command> shell. While logged in as user
    12 <emphasis>lfs</emphasis>, issue the
    13 following command to create a new <filename>.bash_profile</filename>:</para>
     11  <title>Setting Up the Environment</title>
     12
     13  <para>Set up a good working environment by creating two new startup files
     14  for the <command>bash</command> shell. While logged in as user
     15  <systemitem class="username">lfs</systemitem>, issue the following command
     16  to create a new <filename>.bash_profile</filename>:</para>
    1417
    1518<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
    … …  
    1720EOF</userinput></screen>
    1821
    19 <para>When logged on as user <emphasis>lfs</emphasis>, the
    20 initial shell is usually a <emphasis>login</emphasis> shell which reads the
    21 <filename>/etc/profile</filename> of the host (probably containing
    22 some settings and environment variables) and then
    23 <filename>.bash_profile</filename>. The <command>exec env
    24 -i.../bin/bash</command> command in the
    25 <filename>.bash_profile</filename> file replaces the running shell
    26 with a new one with a completely empty environment, except for the
    27 <envar>HOME</envar>, <envar>TERM</envar>, and
    28 <envar>PS1</envar> variables. This ensures that no unwanted and
    29 potentially hazardous environment variables from the host system leak
    30 into the build environment. The technique used here achieves the goal
    31 of ensuring a clean environment.</para>
     22  <para>When logged on as user <systemitem class="username">lfs</systemitem>,
     23  the initial shell is usually a <emphasis>login</emphasis> shell which reads
     24  the <filename>/etc/profile</filename> of the host (probably containing some
     25  settings and environment variables) and then <filename>.bash_profile</filename>.
     26  The <command>exec env -i.../bin/bash</command> command in the
     27  <filename>.bash_profile</filename> file replaces the running shell with a new
     28  one with a completely empty environment, except for the <envar>HOME</envar>,
     29  <envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no
     30  unwanted and potentially hazardous environment variables from the host system
     31  leak into the build environment. The technique used here achieves the goal of
     32  ensuring a clean environment.</para>
    3233
    33 <para>The new instance of the shell is a <emphasis>non-login</emphasis>
    34 shell, which does not read the <filename>/etc/profile</filename> or
    35 <filename>.bash_profile</filename> files, but rather reads the
    36 <filename>.bashrc</filename> file instead. Create the
    37 <filename>.bashrc</filename> file now:</para>
     34  <para>The new instance of the shell is a <emphasis>non-login</emphasis>
     35  shell, which does not read the <filename>/etc/profile</filename> or
     36  <filename>.bash_profile</filename> files, but rather reads the
     37  <filename>.bashrc</filename> file instead. Create the
     38  <filename>.bashrc</filename> file now:</para>
    3839
    3940<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
    … …  
    4647EOF</userinput></screen>
    4748
    48 <para>The <command>set +h</command> command turns off
    49 <command>bash</command>'s hash function. Hashing is ordinarily a useful
    50 feature&mdash;<command>bash</command> uses a hash table to remember the
    51 full path of executable files to avoid searching the <envar>PATH</envar> time
    52 and again to find the same executable. However, the new tools
    53 should be used as soon as they are installed. By switching off the
    54 hash function, the shell will always search the <envar>PATH</envar> when a program is
    55 to be run. As such, the shell will find the newly compiled
    56 tools in <filename class="directory">$LFS/tools</filename> as soon as
    57 they are available without remembering a previous version of the same
    58 program in a different location.</para>
     49  <para>The <command>set +h</command> command turns off
     50  <command>bash</command>'s hash function. Hashing is ordinarily a useful
     51  feature&mdash;<command>bash</command> uses a hash table to remember the
     52  full path of executable files to avoid searching the <envar>PATH</envar>
     53  time and again to find the same executable. However, the new tools should
     54  be used as soon as they are installed. By switching off the hash function,
     55  the shell will always search the <envar>PATH</envar> when a program is to
     56  be run. As such, the shell will find the newly compiled tools in
     57  <filename class="directory">$LFS/tools</filename> as soon as they are
     58  available without remembering a previous version of the same program in a
     59  different location.</para>
    5960
    60 <para>Setting the user file-creation mask (umask) to 022 ensures that newly
    61 created files and directories are only writable by their owner, but
    62 are readable and executable by anyone (assuming default modes are used
    63 by the open(2) system call, new files will end up with permission mode
    64 644 and directories with mode 755).</para>
     61  <para>Setting the user file-creation mask (umask) to 022 ensures that newly
     62  created files and directories are only writable by their owner, but are
     63  readable and executable by anyone (assuming default modes are used by the
     64  <function>open(2)</function> system call, new files will end up with permission
     65  mode 644 and directories with mode 755).</para>
    6566
    66 <para>The <envar>LFS</envar> variable should be set to the
    67 chosen mount point.</para>
     67  <para>The <envar>LFS</envar> variable should be set to the chosen mount
     68  point.</para>
    6869
    69 <para>The <envar>LC_ALL</envar> variable controls the
    70 localization of certain programs, making their messages follow the
    71 conventions of a specified country.  If the host system uses a version
    72 of Glibc older than 2.2.4, having <envar>LC_ALL</envar> set to something other than
    73 <quote>POSIX</quote> or <quote>C</quote> (during this chapter) may
    74 cause issues if you exit the chroot environment and wish to return
    75 later. Setting <envar>LC_ALL</envar> to <quote>POSIX</quote>
    76 or <quote>C</quote> (the two are equivalent) ensures that
    77 everything will work as expected in the chroot environment.</para>
     70  <para>The <envar>LC_ALL</envar> variable controls the localization of certain
     71  programs, making their messages follow the conventions of a specified country.
     72  If the host system uses a version of Glibc older than 2.2.4, having
     73  <envar>LC_ALL</envar> set to something other than <quote>POSIX</quote> or
     74  <quote>C</quote> (during this chapter) may cause issues if you exit the chroot
     75  environment and wish to return later. Setting <envar>LC_ALL</envar> to
     76  <quote>POSIX</quote> or <quote>C</quote> (the two are equivalent) ensures that
     77  everything will work as expected in the chroot environment.</para>
    7878
    79 <para>By putting <filename class="directory">/tools/bin</filename> ahead of the
    80 standard <envar>PATH</envar>, all the programs installed in <xref
    81 linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
    82 their installation. This, combined with turning off hashing, limits the risk
    83 that old programs are used from the host when the same programs are available in
    84 the chapter 5 environment.</para>
     79  <para>By putting <filename class="directory">/tools/bin</filename> ahead of the
     80  standard <envar>PATH</envar>, all the programs installed in <xref
     81  linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
     82  their installation. This, combined with turning off hashing, limits the risk
     83  that old programs are used from the host when the same programs are available in
     84  the chapter 5 environment.</para>
    8585
    86 <para>Finally, to have the environment fully prepared for building the
    87 temporary tools, source the just-created user profile:</para>
     86  <para>Finally, to have the environment fully prepared for building the
     87  temporary tools, source the just-created user profile:</para>
    8888
    8989<screen><userinput>source ~/.bash_profile</userinput></screen>
    9090
    9191</sect1>
    92 
Note: See TracChangeset for help on using the changeset viewer.