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

Small textual adjustments.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3162 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud 2004-01-12 23:24:06 +00:00
parent 5888299528
commit f4993cfc75
11 changed files with 71 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
chapter05/chapter05.xml
View File

@ -77,7 +77,7 @@ words, more advanced techniques could be used to build the system.</para>
<important>
<para>Before continuing, you really should be aware of the name of your working
platform, often also referred to as the <emphasis>target triplet</emphasis>. For
many folks the target triplet will be, for example:
many folks the target triplet will probably be
<emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
triplet is to run the <filename>config.guess</filename> script that comes with
the source for many packages. Unpack the Binutils sources and run the script:
@ -88,7 +88,7 @@ the source for many packages. Unpack the Binutils sources and run the script:
<emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
<emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided
by Glibc and has the job of finding and loading the shared libraries needed by a
program, preparing the program to run and then running it. For most folks, the
program, preparing the program to run and then running it. For most folks the
name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On
platforms that are less prevalent, the name might be
<emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have
@ -266,12 +266,13 @@ programs compiled in the next chapter. The programs compiled here are only
temporary tools and won't be a part of the final LFS system and by keeping them
in a separate directory, we can later easily throw them away.</para>
<para>If later you wish to search through the binaries of your system to see
what files they make use of or link against, then to make this searching easier
you may want to choose a unique name. Instead of the simple "tools" you could
use something like "tools-for-lfs". However, you'll need to be careful to
adjust all references to "tools" throughout the book including those in any
patches, the most notable being the GCC Specs Patch.</para>
<para>Later on you might wish to search through the binaries of your system to
see what files they make use of or link against. To make this searching easier
you may want to choose a unique name for the directory in which the temporary
tools are stored. Instead of the simple "tools" you could use something like
"tools-for-lfs". However, you'll need to be careful to adjust all references to
"tools" throughout the book -- including those in any patches, notably the
GCC Specs Patch.</para>
<para>Create the required directory by running the following:</para>
@ -283,17 +284,16 @@ partition:</para>
<screen><userinput>ln -s $LFS/tools /</userinput></screen>
<para>This symlink enables us to compile our toolchain so that it always
<note><para>The above command is correct. The <userinput>ln</userinput> command
has a few syntactic variations, so be sure to check the info page before
reporting what you may think is an error.</para></note>
<para>The created symlink enables us to compile our toolchain so that it always
refers to <filename>/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) <emphasis>and</emphasis> in the next (when we are chrooted to
the LFS partition).</para>
<note><para>Study the above command closely. It can be confusing at first
glance. The <userinput>ln</userinput> command has several syntax variations,
so be sure to check the ln man page before reporting what you may think is an
error.</para></note>
</sect1>
@ -330,7 +330,7 @@ user command:</para>
<screen><userinput>su - lfs</userinput></screen>
<para>The "<userinput>-</userinput>" instructs <userinput>su</userinput> to
start a new, clean shell.</para>
start a <emphasis>login</emphasis> shell.</para>
</sect1>
@ -340,27 +340,29 @@ start a new, clean shell.</para>
<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
<para>We're going to set up a good working environment by creating two new
startup files for the Bash shell. While logged in as user
<emphasis>lfs</emphasis>, issue the following commands to create a new
startup files for the <userinput>bash</userinput> shell. While logged in as
user <emphasis>lfs</emphasis>, issue the following command to create a new
<filename>.bash_profile</filename>:</para>
<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"</userinput>
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
<userinput>EOF</userinput></screen>
<para>The
<userinput>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</userinput>
command creates a new instance of Bash with a completely empty environment,
except for the HOME, TERM and PS1 variables. This is needed to ensure that no
unwanted and potentially hazardous environment variables from the host system
leak into our build environment. The technique used here is a little
non-standard but it achieves the goal of enforcing a clean environment. By way
of explanation, the initial shell is a <emphasis>login</emphasis> shell which
reads the <filename>.bash_profile</filename>. The new shell instance is a
<emphasis>non-login</emphasis> shell which reads the
<filename>.bashrc</filename> (created next).</para>
<para>Normally, when you log on as user <emphasis>lfs</emphasis>,
the initial shell is a <emphasis>login</emphasis> shell which reads the
<filename>/etc/profile</filename> of your host (probably containing some
settings of environment variables) and then <filename>.bash_profile</filename>.
The <userinput>exec env -i ... /bin/bash</userinput> command in the latter file
replaces the running shell with a new one with a completely empty environment,
except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
potentially hazardous environment variables from the host system leak into our
build environment. The technique used here is a little strange, but it achieves
the goal of enforcing a clean environment.</para>
<para>Now create a new <filename>.bashrc</filename>:</para>
<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
which doesn't read the <filename>/etc/profile</filename> or
<filename>.bash_profile</filename> files, but reads the
<filename>.bashrc</filename> file instead. Create this latter file now:</para>
<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"</userinput>
set +h
@ -401,8 +403,8 @@ everything will work as expected in the chroot environment.</para>
that, as we move along through this chapter, the tools we build will get used
during the rest of the building process.</para>
<para>Finally, source the just-created profile so that we're all set to begin
building the temporary tools that will support us in later chapters.</para>
<para>Finally, to have our environment fully prepared for building the
temporary tools, source the just-created profile:</para>
<screen><userinput>source ~/.bash_profile</userinput></screen>
@ -436,10 +438,10 @@ pass of Binutils. From this point onwards everything will link <emphasis>only
<note><para>If you somehow missed the earlier warning to retain the Binutils
source and build directories from the first pass or otherwise accidentally
deleted them or just don't have access to them, don't worry, all is not lost.
Just ignore the above command. The result is a small chance of subsequent
programs linking against libraries on the host. This is not ideal, however,
Just ignore the above command. The result is a small chance of the subsequent
testing programs linking against libraries on the host. This is not ideal, but
it's not a major problem. The situation is corrected when we install the
second pass of Binutils later on.</para></note>
second pass of Binutils a bit further on.</para></note>
<para>Now that the adjusted linker is installed, you have to remove the
Binutils build and source directories.</para>

6
chapter05/expect.xml
View File

@ -45,10 +45,10 @@ libraries, both of which may possibly reside on the host system.</para></listite
<screen><userinput>make</userinput></screen>
<para>This package has a test suite available which can perform a number of
checks to ensure it built correctly. However, the Expect test suite here in
Chapter 5 is known to experience failures under certain host conditions that
checks to ensure it built correctly. However, the Expect test suite
is known to experience failures under certain host conditions that
are not fully understood. Therefore, test suite failures here are not
surprising, but are not considered critical. Should you choose to run the test
surprising, and are not considered critical. Should you choose to run the test
suite, the following command will do so:</para>
<screen><userinput>make test</userinput></screen>

2
chapter05/findutils.xml
View File

@ -11,7 +11,7 @@ Estimated required disk space: &findutils-compsize-tools;</screen>
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installing Findutils</title>
<title>Installation of Findutils</title>
<para>Prepare Findutils for compilation:</para>

4
chapter05/gcc-pass2.xml
View File

@ -64,8 +64,8 @@ ensures that our new dynamic linker gets used during the actual build of GCC.
That is, all the final (and temporary) binaries created during the build will
link against the new Glibc.</para>
<important><para>These patches are <emphasis>critical</emphasis> in ensuring a
successful overall build. Do not forget to apply them.</para></important>
<important><para>The above patches are <emphasis>critical</emphasis> in ensuring
a successful overall build. Do not forget to apply them.</para></important>
<para>Create a separate build directory again:</para>

4
chapter05/gettext.xml
View File

@ -22,8 +22,8 @@ Estimated required disk space: &gettext-compsize-tools;</screen>
<screen><userinput>make</userinput></screen>
<para>This package has a test suite available which can perform a number of
checks to ensure it built correctly. However, the Gettext test suite here in
Chapter 5 is known to experience failures under certain host conditions -- for
checks to ensure it built correctly. However, the Gettext test suite is known
to experience failures under certain host conditions -- for
example, if it finds a Java compiler on the host (Note: an experimental patch
to disable Java is available from the patches project). The Gettext test suite
takes a very long time to run and is not considered critical. Therefore,

14
chapter05/tcl.xml
View File

@ -44,8 +44,8 @@ following command will do so:</para>
<listitem><para><userinput>TZ=UTC</userinput>: This sets the time zone to
Coordinated Universal Time (UTC) also known as Greenwich Mean Time (GMT), but
only for the duration of the test suite run. This ensures the clock tests are
exercised correctly. More information on the TZ environment variable is
available later on in <xref linkend="chapter07"/>.</para></listitem>
exercised correctly. More information on the TZ environment variable will be
given later on in <xref linkend="chapter07"/>.</para></listitem>
</itemizedlist>
<para>Sometimes, package test suites will give false failures. You can
@ -57,9 +57,15 @@ throughout the book.</para>
<screen><userinput>make install</userinput></screen>
<important><para><emphasis>Do not remove</emphasis> the
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
<warning><para><emphasis>Do not remove</emphasis> the
<filename>tcl&tcl-version;</filename> source directory yet, as the next package
will need its internal headers.</para></important>
will need its internal headers.</para></warning>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
<para>Make a necessary symbolic link:</para>

3
chapter05/utillinux.xml
View File

@ -14,7 +14,8 @@ Estimated required disk space: &util-linux-compsize-tools;</screen>
<title>Installation of Util-linux</title>
<para>Util-linux doesn't use the freshly installed headers and libraries from
the /tools directory. This is fixed by altering the configure script:</para>
the <filename>/tools</filename> directory. This is fixed by altering the
configure script:</para>
<screen><userinput>cp configure configure.backup
sed "s@/usr/include@/tools/include@g" configure.backup &gt; configure</userinput></screen>

2
chapter06/bash.xml
View File

@ -21,7 +21,7 @@ patch:</para>
<screen><userinput>patch -Np1 -i ../&bash-patch;</userinput></screen>
<para>Prepare Bash for compilation:</para>
<para>Now prepare Bash for compilation:</para>
<screen><userinput>./configure --prefix=/usr --bindir=/bin</userinput></screen>

11
chapter06/findutils.xml
View File

@ -15,17 +15,16 @@ Estimated required disk space: &findutils-compsize;</screen>
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installing Findutils</title>
<title>Installation of Findutils</title>
<para>Prepare Findutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr --libexecdir=/usr/lib/locate</userinput></screen>
<para>By default, the location of the updatedb database is in
<filename>/usr/var</filename>. To make the location of
<filename>/var/lib/misc/locatedb</filename> file FHS compliant, pass the
<emphasis>--localstatedir=/var/lib/misc</emphasis> option to
<userinput>configure</userinput>.</para>
<para>The default location for the <emphasis>locate</emphasis> database is
<filename>/usr/var</filename>. To make the location of this database
FHS-compliant, add <emphasis>--localstatedir=/var/lib/misc</emphasis>
to the above configure options.</para>
<para>Compile the package:</para>

16
chapter06/inetutils.xml
View File

@ -23,25 +23,25 @@ pages anyway. The following patch will correct this situation:</para>
<para>Now prepare Inetutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr --disable-syslogd \
&nbsp;&nbsp;&nbsp;&nbsp;--libexecdir=/usr/sbin --disable-logger \
<screen><userinput>./configure --prefix=/usr --libexecdir=/usr/sbin \
&nbsp;&nbsp;&nbsp;&nbsp;--sysconfdir=/etc --localstatedir=/var \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-logger --disable-syslogd \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-whois --disable-servers</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--disable-syslogd</userinput>: This option
prevents inetutils from installing the System Log Daemon, which is
installed with the Sysklogd package.</para></listitem>
<listitem><para><userinput>--disable-logger</userinput>: This option
prevents inetutils from installing the logger program, which is used by
prevents Inetutils from installing the logger program, which is used by
scripts to pass messages to the System Log Daemon. We do not install it
because Util-linux installs a better version later.</para></listitem>
<listitem><para><userinput>--disable-syslogd</userinput>: This option
prevents Inetutils from installing the System Log Daemon, which is
installed with the Sysklogd package.</para></listitem>
<listitem><para><userinput>--disable-whois</userinput>: This option disables
the building of the inetutils whois client, which is woefully out of date.
the building of the Inetutils whois client, which is woefully out of date.
Instructions for a better whois client are in the BLFS book.</para></listitem>
<listitem><para><userinput>--disable-servers</userinput>: This disables the

2
preface/prerequisites.xml
View File

@ -10,7 +10,7 @@ system, you should read the following HOWTOs:</para>
<listitem><para>Software-Building-HOWTO</para>
<para>This is a comprehensive guide to building and installing "generic"
UNIX software distributions under Linux. This HOWTO is available at
Unix software distributions under Linux. This HOWTO is available at
<ulink url="&tldp-root;HOWTO/Software-Building-HOWTO.html"/>.</para></listitem>
<listitem><para>The Linux Users' Guide</para>