mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-06-18 19:29:21 +01:00
Indented chapter 04.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7275 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Manuel Canales Esparcia
parent
b0ed1af225
commit
6a3b6af435
@ -1,35 +1,39 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
<sect1 id="prepare-aboutlfs">
|
||||
<title>About $LFS</title>
|
||||
<?dbhtml filename="aboutlfs.html"?>
|
||||
|
||||
<para>Throughout this book, the environment variable <envar>LFS</envar> will
|
||||
be used several times. It is paramount that this variable is always defined.
|
||||
It should be set to the mount point chosen for the LFS partition.
|
||||
Check that the <envar>LFS</envar> variable is set up properly with:</para>
|
||||
<sect1 id="prepare-aboutlfs">
|
||||
<?dbhtml filename="aboutlfs.html"?>
|
||||
|
||||
<title>About $LFS</title>
|
||||
|
||||
<para>Throughout this book, the environment variable <envar>LFS</envar> will
|
||||
be used several times. It is paramount that this variable is always defined.
|
||||
It should be set to the mount point chosen for the LFS partition.
|
||||
Check that the <envar>LFS</envar> variable is set up properly with:</para>
|
||||
|
||||
<screen role="nodump"><userinput>echo $LFS</userinput></screen>
|
||||
|
||||
<para>Make sure the output shows the path to the LFS partition's mount
|
||||
point, which is <filename class="directory">/mnt/lfs</filename> if the
|
||||
provided example was followed. If the output is incorrect, the
|
||||
variable can be set with:</para>
|
||||
<para>Make sure the output shows the path to the LFS partition's mount
|
||||
point, which is <filename class="directory">/mnt/lfs</filename> if the
|
||||
provided example was followed. If the output is incorrect, the
|
||||
variable can be set with:</para>
|
||||
|
||||
<screen role="nodump"><userinput>export LFS=/mnt/lfs</userinput></screen>
|
||||
|
||||
<para>Having this variable set is beneficial in that commands such as
|
||||
<command>mkdir $LFS/tools</command> can be typed literally. The shell
|
||||
will automatically replace <quote>$LFS</quote> with
|
||||
<quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
|
||||
processes the command line.</para>
|
||||
<para>Having this variable set is beneficial in that commands such as
|
||||
<command>mkdir $LFS/tools</command> can be typed literally. The shell
|
||||
will automatically replace <quote>$LFS</quote> with
|
||||
<quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
|
||||
processes the command line.</para>
|
||||
|
||||
<para>Do not forget to check that <envar>$LFS</envar> is set whenever
|
||||
you leave and reenter the current working environment (as when doing a
|
||||
<quote>su</quote> to <emphasis>root</emphasis> or another user).</para>
|
||||
<para>Do not forget to check that <envar>$LFS</envar> is set whenever
|
||||
you leave and reenter the current working environment (as when doing a
|
||||
<command>su</command> to <systemitem class="username">root</systemitem>
|
||||
or another user).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -1,42 +1,45 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
|
||||
<sect1 id="prepare-aboutsbus">
|
||||
<title>About SBUs</title>
|
||||
<?dbhtml filename="aboutsbus.html"?>
|
||||
<?dbhtml filename="aboutsbus.html"?>
|
||||
|
||||
<para>Many people would like to know beforehand approximately how long
|
||||
it takes to compile and install each package. Because Linux From
|
||||
Scratch can be built on many different systems, it is impossible to
|
||||
provide accurate time estimates. The biggest package (Glibc) will
|
||||
take approximately 20 minutes on the fastest systems, but could take
|
||||
up to three days on slower systems! Instead of providing actual times,
|
||||
the Standard Build Unit (SBU) measure will be
|
||||
used instead.</para>
|
||||
<title>About SBUs</title>
|
||||
|
||||
<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
|
||||
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>Many people would like to know beforehand approximately how long
|
||||
it takes to compile and install each package. Because Linux From
|
||||
Scratch can be built on many different systems, it is impossible to
|
||||
provide accurate time estimates. The biggest package (Glibc) will
|
||||
take approximately 20 minutes on the fastest systems, but could take
|
||||
up to three days on slower systems! Instead of providing actual times,
|
||||
the Standard Build Unit (SBU) measure will be
|
||||
used instead.</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
|
||||
<emphasis>approximately</emphasis> 45 minutes to build this example package.
|
||||
Fortunately, most build times are shorter than the one for Binutils.</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
|
||||
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>In general, SBUs are not entirely accurate because they depend on many
|
||||
factors, including the host system's version of GCC. Note that on Symmetric
|
||||
Multi-Processor (SMP)-based machines, SBUs are even less accurate. They are
|
||||
provided here to give an estimate of how long it might take to install a
|
||||
package, but the numbers can vary by as much as dozens of minutes in some
|
||||
cases.</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
|
||||
<emphasis>approximately</emphasis> 45 minutes to build this example package.
|
||||
Fortunately, most build times are shorter than the one for Binutils.</para>
|
||||
|
||||
<para>To view actual timings for a number of specific machines, we recommend
|
||||
The LinuxFromScratch SBU Home Page at <ulink url="&lfs-root;~bdubbs/"/>.</para>
|
||||
<para>In general, SBUs are not entirely accurate because they depend on many
|
||||
factors, including the host system's version of GCC. Note that on Symmetric
|
||||
Multi-Processor (SMP)-based machines, SBUs are even less accurate. They are
|
||||
provided here to give an estimate of how long it might take to install a
|
||||
package, but the numbers can vary by as much as dozens of minutes in some
|
||||
cases.</para>
|
||||
|
||||
<para>To view actual timings for a number of specific machines, we recommend
|
||||
The LinuxFromScratch SBU Home Page at <ulink url="&lfs-root;~bdubbs/"/>.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -1,50 +1,52 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
|
||||
<sect1 id="prepare-abouttestsuites">
|
||||
<title>About the Test Suites</title>
|
||||
<?dbhtml filename="abouttestsuites.html"?>
|
||||
<?dbhtml filename="abouttestsuites.html"?>
|
||||
|
||||
<para>Most packages provide a test suite. Running the test suite for a
|
||||
newly built package is a good idea because it can provide a <quote>sanity
|
||||
check</quote> indicating that everything compiled correctly. A test suite
|
||||
that passes its set of checks usually proves that the package is
|
||||
functioning as the developer intended. It does not, however, guarantee
|
||||
that the package is totally bug free.</para>
|
||||
<title>About the Test Suites</title>
|
||||
|
||||
<para>Some test suites are more important than others. For example,
|
||||
the test suites for the core toolchain packages—GCC, Binutils, and
|
||||
Glibc—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>
|
||||
<para>Most packages provide a test suite. Running the test suite for a
|
||||
newly built package is a good idea because it can provide a <quote>sanity
|
||||
check</quote> indicating that everything compiled correctly. A test suite
|
||||
that passes its set of checks usually proves that the package is
|
||||
functioning as the developer intended. It does not, however, guarantee
|
||||
that the package is totally bug free.</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></note>
|
||||
<para>Some test suites are more important than others. For example,
|
||||
the test suites for the core toolchain packages—GCC, Binutils, and
|
||||
Glibc—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>
|
||||
|
||||
<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
|
||||
<systemitem class="filesystem">devpts</systemitem> file system set up
|
||||
correctly. This issue is discussed in greater detail in <xref
|
||||
linkend="chapter-temporary-tools"/>.</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>
|
||||
</note>
|
||||
|
||||
<para>Sometimes package test suites will fail, but for reasons which the
|
||||
developers are aware of and have deemed non-critical. Consult the logs located
|
||||
at <ulink url="&test-results;"/> to verify whether or not these failures are
|
||||
expected. This site is valid for all tests throughout this book.</para>
|
||||
<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
|
||||
<systemitem class="filesystem">devpts</systemitem> file system set up
|
||||
correctly. This issue is discussed in greater detail in <xref
|
||||
linkend="chapter-temporary-tools"/>.</para>
|
||||
|
||||
<para>Sometimes package test suites will fail, but for reasons which the
|
||||
developers are aware of and have deemed non-critical. Consult the logs located
|
||||
at <ulink url="&test-results;"/> to verify whether or not these failures are
|
||||
expected. This site is valid for all tests throughout this book.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -1,90 +1,102 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
<sect1 id="ch-tools-addinguser">
|
||||
<title>Adding the LFS User</title>
|
||||
<?dbhtml filename="addinguser.html"?>
|
||||
|
||||
<para>When logged in as user <emphasis>root</emphasis>, making a single mistake
|
||||
can damage or destroy a system. Therefore, we recommend building the packages in
|
||||
this chapter 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
|
||||
<emphasis>lfs</emphasis> as a member of a new group (also named
|
||||
<emphasis>lfs</emphasis>) and use this user during the installation process. As
|
||||
<emphasis>root</emphasis>, issue the following commands to add the new
|
||||
user:</para>
|
||||
<sect1 id="ch-tools-addinguser">
|
||||
<?dbhtml filename="addinguser.html"?>
|
||||
|
||||
<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 this chapter 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
|
||||
<systemitem class="groupname">lfs</systemitem>) and use this user during
|
||||
the installation process. As <systemitem class="username">root</systemitem>,
|
||||
issue the following commands to add the new user:</para>
|
||||
|
||||
<screen><userinput>groupadd lfs
|
||||
useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
|
||||
|
||||
<para>The meaning of the command line options:</para>
|
||||
<variablelist>
|
||||
<title>The meaning of the command line options:</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>-s /bin/bash</parameter></term>
|
||||
<listitem><para>This makes
|
||||
<command>bash</command> the default shell for user
|
||||
<emphasis>lfs</emphasis>.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>-s /bin/bash</parameter></term>
|
||||
<listitem>
|
||||
<para>This makes <command>bash</command> the default shell for user
|
||||
<systemitem class="username">lfs</systemitem>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-g lfs</parameter></term>
|
||||
<listitem><para>This option adds user <emphasis>lfs</emphasis> to group
|
||||
<emphasis>lfs</emphasis>.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>-g lfs</parameter></term>
|
||||
<listitem>
|
||||
<para>This option adds user <systemitem class="username">lfs</systemitem>
|
||||
to group <systemitem class="groupname">lfs</systemitem>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-m</parameter></term>
|
||||
<listitem><para>This creates a home
|
||||
directory for <emphasis>lfs</emphasis>.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>-m</parameter></term>
|
||||
<listitem>
|
||||
<para>This creates a home directory for <systemitem
|
||||
class="username">lfs</systemitem>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>-k /dev/null</parameter></term>
|
||||
<listitem><para>This parameter
|
||||
prevents possible copying of files from a skeleton directory (default
|
||||
is <filename class="directory">/etc/skel</filename>) by changing the input location to
|
||||
the special null device.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>-k /dev/null</parameter></term>
|
||||
<listitem>
|
||||
<para>This parameter prevents possible copying of files from a skeleton
|
||||
directory (default is <filename class="directory">/etc/skel</filename>)
|
||||
by changing the input location to the special null device.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>lfs</parameter></term>
|
||||
<listitem><para>This is the actual name for the created group and
|
||||
user.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>lfs</parameter></term>
|
||||
<listitem>
|
||||
<para>This is the actual name for the created group and user.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<para>To log in as <emphasis>lfs</emphasis> (as opposed to switching
|
||||
to user <emphasis>lfs</emphasis> when
|
||||
logged in as <emphasis>root</emphasis>, which does not require the
|
||||
<emphasis>lfs</emphasis> user to have a
|
||||
password), give <emphasis>lfs</emphasis> a password:</para>
|
||||
</variablelist>
|
||||
|
||||
<para>To log in as <systemitem class="username">lfs</systemitem> (as opposed
|
||||
to switching to user <systemitem class="username">lfs</systemitem> when logged
|
||||
in as <systemitem class="username">root</systemitem>, which does not require
|
||||
the <systemitem class="username">lfs</systemitem> user to have a password),
|
||||
give <systemitem class="username">lfs</systemitem> a password:</para>
|
||||
|
||||
<screen role="nodump"><userinput>passwd lfs</userinput></screen>
|
||||
|
||||
<para>Grant <emphasis>lfs</emphasis> full access to
|
||||
<filename class="directory">$LFS/tools</filename> by making
|
||||
<emphasis>lfs</emphasis> the directory owner:</para>
|
||||
<para>Grant <systemitem class="username">lfs</systemitem> full access to
|
||||
<filename class="directory">$LFS/tools</filename> by making
|
||||
<systemitem class="username">lfs</systemitem> the directory owner:</para>
|
||||
|
||||
<screen><userinput>chown -v lfs $LFS/tools</userinput></screen>
|
||||
|
||||
<para>If a separate working directory was created as suggested, give
|
||||
user <emphasis>lfs</emphasis> ownership of this directory:</para>
|
||||
<para>If a separate working directory was created as suggested, give
|
||||
user <systemitem class="username">lfs</systemitem> ownership of this
|
||||
directory:</para>
|
||||
|
||||
<screen><userinput>chown -v lfs $LFS/sources</userinput></screen>
|
||||
|
||||
<para>Next, login as user <emphasis>lfs</emphasis>. This can be done
|
||||
via a virtual console, through a display manager, or with the
|
||||
following substitute user command:</para>
|
||||
<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>
|
||||
|
||||
<screen><userinput>su - lfs</userinput></screen>
|
||||
<screen role="nodump"><userinput>su - lfs</userinput></screen>
|
||||
|
||||
<para>The <quote><parameter>-</parameter></quote> instructs
|
||||
<command>su</command> to start a login shell as opposed to a non-login shell.
|
||||
The difference between these two types of shells can be found in detail in
|
||||
<filename>bash(1)</filename> and <command>info bash</command>.</para>
|
||||
<para>The <quote><parameter>-</parameter></quote> instructs
|
||||
<command>su</command> to start a login shell as opposed to a non-login shell.
|
||||
The difference between these two types of shells can be found in detail in
|
||||
<filename>bash(1)</filename> and <command>info bash</command>.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -1,18 +1,21 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
<chapter id="chapter-final-preps" xreflabel="Chapter 4">
|
||||
<?dbhtml dir="chapter04"?>
|
||||
<title>Final Preparations</title>
|
||||
<?dbhtml filename="chapter04.html"?>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
|
||||
<chapter id="chapter-final-preps" xreflabel="Chapter 4">
|
||||
<?dbhtml dir="chapter04"?>
|
||||
<?dbhtml filename="chapter04.html"?>
|
||||
|
||||
<title>Final Preparations</title>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
|
||||
|
||||
</chapter>
|
||||
|
||||
@ -1,46 +1,48 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
|
||||
<sect1 id="ch-tools-creatingtoolsdir">
|
||||
<title>Creating the $LFS/tools Directory</title>
|
||||
<?dbhtml filename="creatingtoolsdir.html"?>
|
||||
<?dbhtml filename="creatingtoolsdir.html"?>
|
||||
|
||||
<para>All programs compiled in <xref
|
||||
linkend="chapter-temporary-tools"/> will be installed under <filename
|
||||
class="directory">$LFS/tools</filename> to keep them separate from the
|
||||
programs compiled in <xref linkend="chapter-building-system"/>. The
|
||||
programs compiled here are temporary tools and will not be a part of
|
||||
the final LFS system. By keeping these programs in a separate
|
||||
directory, they can easily be discarded later after their use. This
|
||||
also prevents these programs from ending up in the host production
|
||||
directories (easy to do by accident in <xref
|
||||
linkend="chapter-temporary-tools"/>).</para>
|
||||
<title>Creating the $LFS/tools Directory</title>
|
||||
|
||||
<para>Create the required directory by running the following as
|
||||
<emphasis>root</emphasis>:</para>
|
||||
<para>All programs compiled in <xref linkend="chapter-temporary-tools"/>
|
||||
will be installed under <filename class="directory">$LFS/tools</filename>
|
||||
to keep them separate from the programs compiled in <xref
|
||||
linkend="chapter-building-system"/>. The programs compiled here are
|
||||
temporary tools and will not be a part of the final LFS system. By keeping
|
||||
these programs in a separate directory, they can easily be discarded later
|
||||
after their use. This also prevents these programs from ending up in the
|
||||
host production directories (easy to do by accident in <xref
|
||||
linkend="chapter-temporary-tools"/>).</para>
|
||||
|
||||
<para>Create the required directory by running the following as
|
||||
<systemitem class="username">root</systemitem>:</para>
|
||||
|
||||
<screen><userinput>mkdir -v $LFS/tools</userinput></screen>
|
||||
|
||||
<para>The next step is to create a <filename class="symlink">/tools</filename>
|
||||
symlink on the host system. This will point to the newly-created directory on
|
||||
the LFS partition. Run this command as <emphasis>root</emphasis> as
|
||||
well:</para>
|
||||
<para>The next step is to create a <filename class="symlink">/tools</filename>
|
||||
symlink on the host system. This will point to the newly-created directory on
|
||||
the LFS partition. Run this command as <systemitem
|
||||
class="username">root</systemitem> as well:</para>
|
||||
|
||||
<screen><userinput>ln -sv $LFS/tools /</userinput></screen>
|
||||
|
||||
<note><para>The above command is correct. The <command>ln</command> command has
|
||||
a few syntactic variations, so be sure to check <command>info coreutils ln</command> and
|
||||
<filename>ln(1)</filename> before reporting what you may think is an
|
||||
error.</para></note>
|
||||
<note>
|
||||
<para>The above command is correct. The <command>ln</command> command
|
||||
has a few syntactic variations, so be sure to check
|
||||
<command>info coreutils ln</command> and <filename>ln(1)</filename>
|
||||
before reporting what you may think is an error.</para>
|
||||
</note>
|
||||
|
||||
<para>The created symlink enables the toolchain to be compiled so that
|
||||
it always refers to <filename class="directory">/tools</filename>,
|
||||
meaning that the compiler, assembler, and linker will work both in
|
||||
this chapter (when we are still using some tools from the host) and in
|
||||
the next (when we are <quote>chrooted</quote> to the LFS
|
||||
partition).</para>
|
||||
<para>The created symlink enables the toolchain to be compiled so that it
|
||||
always refers to <filename class="directory">/tools</filename>, meaning
|
||||
that the compiler, assembler, and linker will work both in this chapter
|
||||
(when we are still using some tools from the host) and in the next (when
|
||||
we are <quote>chrooted</quote> to the LFS partition).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -1,40 +1,41 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
<sect1 id="ch-tools-settingenviron">
|
||||
<title>Setting Up the Environment</title>
|
||||
<?dbhtml filename="settingenvironment.html"?>
|
||||
|
||||
<para>Set up a good working environment by creating two new startup
|
||||
files for the <command>bash</command> shell. While logged in as user
|
||||
<emphasis>lfs</emphasis>, issue the
|
||||
following command to create a new <filename>.bash_profile</filename>:</para>
|
||||
<sect1 id="ch-tools-settingenviron">
|
||||
<?dbhtml filename="settingenvironment.html"?>
|
||||
|
||||
<title>Setting Up the Environment</title>
|
||||
|
||||
<para>Set up a good working environment by creating two new startup files
|
||||
for the <command>bash</command> shell. While logged in as user
|
||||
<systemitem class="username">lfs</systemitem>, issue the following command
|
||||
to create a new <filename>.bash_profile</filename>:</para>
|
||||
|
||||
<screen><userinput>cat > ~/.bash_profile << "EOF"
|
||||
<literal>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>When logged on as user <emphasis>lfs</emphasis>, the
|
||||
initial shell is usually a <emphasis>login</emphasis> shell which reads the
|
||||
<filename>/etc/profile</filename> of the host (probably containing
|
||||
some settings and environment variables) and then
|
||||
<filename>.bash_profile</filename>. The <command>exec env
|
||||
-i.../bin/bash</command> command in the
|
||||
<filename>.bash_profile</filename> file replaces the running shell
|
||||
with a new one with a completely empty environment, except for the
|
||||
<envar>HOME</envar>, <envar>TERM</envar>, and
|
||||
<envar>PS1</envar> variables. This ensures that no unwanted and
|
||||
potentially hazardous environment variables from the host system leak
|
||||
into the build environment. The technique used here achieves the goal
|
||||
of ensuring a clean environment.</para>
|
||||
<para>When logged on as user <systemitem class="username">lfs</systemitem>,
|
||||
the initial shell is usually a <emphasis>login</emphasis> shell which reads
|
||||
the <filename>/etc/profile</filename> of the host (probably containing some
|
||||
settings and environment variables) and then <filename>.bash_profile</filename>.
|
||||
The <command>exec env -i.../bin/bash</command> command in the
|
||||
<filename>.bash_profile</filename> file replaces the running shell with a new
|
||||
one with a completely empty environment, except for the <envar>HOME</envar>,
|
||||
<envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no
|
||||
unwanted and potentially hazardous environment variables from the host system
|
||||
leak into the build environment. The technique used here achieves the goal of
|
||||
ensuring a clean environment.</para>
|
||||
|
||||
<para>The new instance of the shell is a <emphasis>non-login</emphasis>
|
||||
shell, which does not read the <filename>/etc/profile</filename> or
|
||||
<filename>.bash_profile</filename> files, but rather reads the
|
||||
<filename>.bashrc</filename> file instead. Create the
|
||||
<filename>.bashrc</filename> file now:</para>
|
||||
<para>The new instance of the shell is a <emphasis>non-login</emphasis>
|
||||
shell, which does not read the <filename>/etc/profile</filename> or
|
||||
<filename>.bash_profile</filename> files, but rather reads the
|
||||
<filename>.bashrc</filename> file instead. Create the
|
||||
<filename>.bashrc</filename> file now:</para>
|
||||
|
||||
<screen><userinput>cat > ~/.bashrc << "EOF"
|
||||
<literal>set +h
|
||||
@ -45,48 +46,46 @@ PATH=/tools/bin:/bin:/usr/bin
|
||||
export LFS LC_ALL PATH</literal>
|
||||
EOF</userinput></screen>
|
||||
|
||||
<para>The <command>set +h</command> command turns off
|
||||
<command>bash</command>'s hash function. Hashing is ordinarily a useful
|
||||
feature—<command>bash</command> uses a hash table to remember the
|
||||
full path of executable files to avoid searching the <envar>PATH</envar> time
|
||||
and again to find the same executable. However, the new tools
|
||||
should 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 available without remembering a previous version of the same
|
||||
program in a different location.</para>
|
||||
<para>The <command>set +h</command> command turns off
|
||||
<command>bash</command>'s hash function. Hashing is ordinarily a useful
|
||||
feature—<command>bash</command> uses a hash table to remember the
|
||||
full path of executable files to avoid searching the <envar>PATH</envar>
|
||||
time and again to find the same executable. However, the new tools should
|
||||
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
|
||||
available without remembering a previous version of the same program in a
|
||||
different location.</para>
|
||||
|
||||
<para>Setting the user file-creation mask (umask) to 022 ensures that newly
|
||||
created files and directories are only writable by their owner, but
|
||||
are readable and executable by anyone (assuming default modes are used
|
||||
by the open(2) system call, new files will end up with permission mode
|
||||
644 and directories with mode 755).</para>
|
||||
<para>Setting the user file-creation mask (umask) to 022 ensures that newly
|
||||
created files and directories are only writable by their owner, but are
|
||||
readable and executable by anyone (assuming default modes are used by the
|
||||
<function>open(2)</function> system call, new files will end up with permission
|
||||
mode 644 and directories with mode 755).</para>
|
||||
|
||||
<para>The <envar>LFS</envar> variable should be set to the
|
||||
chosen mount point.</para>
|
||||
<para>The <envar>LFS</envar> variable should be set to the chosen mount
|
||||
point.</para>
|
||||
|
||||
<para>The <envar>LC_ALL</envar> variable controls the
|
||||
localization of certain programs, making their messages follow the
|
||||
conventions of a specified country. If the host system uses a version
|
||||
of Glibc older than 2.2.4, having <envar>LC_ALL</envar> set to something other than
|
||||
<quote>POSIX</quote> or <quote>C</quote> (during this chapter) may
|
||||
cause issues if you exit the chroot environment and wish to return
|
||||
later. 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 chroot environment.</para>
|
||||
<para>The <envar>LC_ALL</envar> variable controls the localization of certain
|
||||
programs, making their messages follow the conventions of a specified country.
|
||||
If the host system uses a version of Glibc older than 2.2.4, having
|
||||
<envar>LC_ALL</envar> set to something other than <quote>POSIX</quote> or
|
||||
<quote>C</quote> (during this chapter) may cause issues if you exit the chroot
|
||||
environment and wish to return later. 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 chroot environment.</para>
|
||||
|
||||
<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>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>Finally, to have the environment fully prepared for building the
|
||||
temporary tools, source the just-created user profile:</para>
|
||||
<para>Finally, to have the environment fully prepared for building the
|
||||
temporary tools, source the just-created user profile:</para>
|
||||
|
||||
<screen><userinput>source ~/.bash_profile</userinput></screen>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user