Finished chapter 05 indentation.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7292 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Manuel Canales Esparcia 2006-01-22 13:13:52 +00:00
parent 7b82580d09
commit b28fd35a82
7 changed files with 493 additions and 405 deletions

View File

@ -1,52 +1,69 @@
<?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-sed" role="wrap">
<title>Sed-&sed-version;</title>
<?dbhtml filename="sed.html"?>
<?dbhtml filename="sed.html"?>
<indexterm zone="ch-tools-sed">
<primary sortas="a-Sed">Sed</primary>
<secondary>tools</secondary></indexterm>
<title>Sed-&sed-version;</title>
<sect2 role="package"><title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/sed.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<indexterm zone="ch-tools-sed">
<primary sortas="a-Sed">Sed</primary>
<secondary>tools</secondary>
</indexterm>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem><seg>0.2 SBU</seg><seg>8.4 MB</seg></seglistitem>
</segmentedlist>
<sect2 role="package">
<title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/sed.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/sed.xml"
xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
</sect2>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<sect2 role="installation">
<title>Installation of Sed</title>
<seglistitem>
<seg>0.2 SBU</seg>
<seg>8.4 MB</seg>
</seglistitem>
</segmentedlist>
<para>Prepare Sed for compilation:</para>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/sed.xml"
xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
</sect2>
<sect2 role="installation">
<title>Installation of Sed</title>
<para>Prepare Sed for compilation:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>To test the results, issue: <userinput>make check</userinput>.</para>
<para>To test the results, issue:
<userinput>make check</userinput>.</para>
<para>Install the package:</para>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect2>
<sect2 role="content"><title/>
<para>Details on this package are located in <xref
linkend="contents-sed" role="."/></para>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-sed" role="."/></para>
</sect2>
</sect1>

View File

@ -1,38 +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="ch-tools-stripping">
<title>Stripping</title>
<?dbhtml filename="stripping.html"?>
<para>The steps in this section are optional, but if the LFS partition
is rather small, it is beneficial to learn that unnecessary items can
be removed. The executables and libraries built so far contain about
130 MB of unneeded debugging symbols. Remove those symbols
with:</para>
<sect1 id="ch-tools-stripping">
<?dbhtml filename="stripping.html"?>
<title>Stripping</title>
<para>The steps in this section are optional, but if the LFS partition is
rather small, it is beneficial to learn that unnecessary items can be removed.
The executables and libraries built so far contain about 130 MB of unneeded
debugging symbols. Remove those symbols with:</para>
<screen><userinput>strip --strip-debug /tools/lib/*
strip --strip-unneeded /tools/{,s}bin/*</userinput></screen>
<para>The last of the above commands will skip some twenty files,
reporting that it does not recognize their file format. Most of these
are scripts instead of binaries.</para>
<para>The last of the above commands will skip some twenty files,
reporting that it does not recognize their file format. Most of these
are scripts instead of binaries.</para>
<para>Take care <emphasis>not</emphasis> to use
<parameter>--strip-unneeded</parameter> on the libraries. The static
ones would be destroyed and the toolchain packages would need to be
built all over again.</para>
<para>Take care <emphasis>not</emphasis> to use
<parameter>--strip-unneeded</parameter> on the libraries. The static
ones would be destroyed and the toolchain packages would need to be
built all over again.</para>
<para>To save another 30 MB, remove the documentation:</para>
<para>To save another 30 MB, remove the documentation:</para>
<screen><userinput>rm -rf /tools/{info,man}</userinput></screen>
<para>There will now be at least 850 MB of free space on the LFS file
system that can be used to build and install Glibc in the next phase.
If you can build and install Glibc, you can build and install the rest
too.</para>
<para>There will now be at least 850 MB of free space on the LFS file
system that can be used to build and install Glibc in the next phase.
If you can build and install Glibc, you can build and install the rest
too.</para>
</sect1>

View File

@ -1,57 +1,74 @@
<?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-tar" role="wrap">
<title>Tar-&tar-version;</title>
<?dbhtml filename="tar.html"?>
<?dbhtml filename="tar.html"?>
<indexterm zone="ch-tools-tar">
<primary sortas="a-Tar">Tar</primary>
<secondary>tools</secondary></indexterm>
<title>Tar-&tar-version;</title>
<sect2 role="package"><title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/tar.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<indexterm zone="ch-tools-tar">
<primary sortas="a-Tar">Tar</primary>
<secondary>tools</secondary>
</indexterm>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem><seg>0.2 SBU</seg><seg>12.7 MB</seg></seglistitem>
</segmentedlist>
<sect2 role="package">
<title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/tar.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/tar.xml"
xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
</sect2>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<sect2 role="installation">
<title>Installation of Tar</title>
<seglistitem>
<seg>0.2 SBU</seg>
<seg>12.7 MB</seg>
</seglistitem>
</segmentedlist>
<para>If you wish to run the test suite, apply the following patch to fix
some issues with GCC-&gcc-version;:</para>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/tar.xml"
xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
</sect2>
<sect2 role="installation">
<title>Installation of Tar</title>
<para>If you wish to run the test suite, apply the following patch to fix
some issues with GCC-&gcc-version;:</para>
<screen><userinput>patch -Np1 -i ../&tar-gcc4_fix-patch;</userinput></screen>
<para>Prepare Tar for compilation:</para>
<para>Prepare Tar for compilation:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>To test the results, issue: <userinput>make check</userinput>.</para>
<para>To test the results, issue:
<userinput>make check</userinput>.</para>
<para>Install the package:</para>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect2>
<sect2 role="content"><title/>
<para>Details on this package are located in <xref
linkend="contents-tar" role="."/></para>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-tar" role="."/></para>
</sect2>
</sect1>

View File

@ -1,119 +1,145 @@
<?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-tcl" role="wrap">
<title>Tcl-&tcl-version;</title>
<?dbhtml filename="tcl.html"?>
<?dbhtml filename="tcl.html"?>
<indexterm zone="ch-tools-tcl"><primary sortas="a-Tcl">Tcl</primary></indexterm>
<title>Tcl-&tcl-version;</title>
<sect2 role="package"><title/>
<para>The Tcl package contains the Tool Command Language.</para>
<indexterm zone="ch-tools-tcl">
<primary sortas="a-Tcl">Tcl</primary>
</indexterm>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem><seg>0.9 SBU</seg><seg>23.3 MB</seg></seglistitem>
</segmentedlist>
<sect2 role="package">
<title/>
<segmentedlist>
<segtitle>&dependencies;</segtitle>
<seglistitem><seg>Bash, Binutils, Coreutils, Diffutils,
GCC, Glibc, Grep, Make, and Sed</seg></seglistitem>
</segmentedlist>
<para>The Tcl package contains the Tool Command Language.</para>
</sect2>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<sect2 role="installation">
<title>Installation of Tcl</title>
<seglistitem>
<seg>0.9 SBU</seg>
<seg>23.3 MB</seg>
</seglistitem>
</segmentedlist>
<para>This package and the next two (Expect and DejaGNU) are
installed to support running the test suites for GCC and Binutils.
Installing three packages for testing purposes may seem excessive, but
it is very reassuring, if not essential, to know that the most
important tools are working properly. Even if the test suites are not
run in this chapter (they are not mandatory), these packages
are required to run the test suites in <xref
linkend="chapter-building-system"/>.</para>
<segmentedlist>
<segtitle>&dependencies;</segtitle>
<seglistitem>
<seg>Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep,
Make, and Sed</seg>
</seglistitem>
</segmentedlist>
</sect2>
<sect2 role="installation">
<title>Installation of Tcl</title>
<para>This package and the next two (Expect and DejaGNU) are installed
to support running the test suites for GCC and Binutils. Installing
three packages for testing purposes may seem excessive, but it is very
reassuring, if not essential, to know that the most important tools are
working properly. Even if the test suites are not run in this chapter
(they are not mandatory), these packages are required to run the test
suites in <xref linkend="chapter-building-system"/>.</para>
<para>Tcl's configure script has a syntax error:</para>
<para>Tcl's configure script has a syntax error:</para>
<screen><userinput>cd unix
cp -v configure{,.orig}
sed "s/relid'/relid/" configure.orig &gt; configure</userinput></screen>
<para>Prepare Tcl for compilation:</para>
<para>Prepare Tcl for compilation:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Build the package:</para>
<para>Build the package:</para>
<screen><userinput>make</userinput></screen>
<para>To test the results, issue: <userinput>TZ=UTC make test</userinput>.
The Tcl test suite is known to experience failures
under certain host conditions that are not fully understood.
Therefore, test suite failures here are not surprising, and are not
considered critical. The <parameter>TZ=UTC</parameter> parameter 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 that the clock tests are exercised correctly.
Details on the <envar>TZ</envar> environment variable are provided in
<xref linkend="chapter-bootscripts"/>.</para>
<para>To test the results, issue: <userinput>TZ=UTC make test</userinput>.
The Tcl test suite is known to experience failures under certain host
conditions that are not fully understood. Therefore, test suite failures
here are not surprising, and are not considered critical. The
<parameter>TZ=UTC</parameter> parameter 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 that the clock tests
are exercised correctly. Details on the <envar>TZ</envar> environment
variable are provided in <xref linkend="chapter-bootscripts"/>.</para>
<para>Install the package:</para>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Install Tcl's headers. The next package, Expect, requires them to build.</para>
<para>Install Tcl's headers. The next package, Expect, requires them
to build.</para>
<screen><userinput>make install-private-headers</userinput></screen>
<para>Now make a necessary symbolic link:</para>
<para>Now make a necessary symbolic link:</para>
<screen><userinput>ln -sv tclsh8.4 /tools/bin/tclsh</userinput></screen>
</sect2>
</sect2>
<sect2 id="contents-tcl" role="content"><title>Contents of Tcl</title>
<sect2 id="contents-tcl" role="content">
<title>Contents of Tcl</title>
<segmentedlist>
<segtitle>Installed programs</segtitle>
<segtitle>Installed library</segtitle>
<seglistitem><seg>tclsh (link to tclsh8.4) and tclsh8.4</seg><seg>libtcl8.4.so</seg></seglistitem>
</segmentedlist>
<segmentedlist>
<segtitle>Installed programs</segtitle>
<segtitle>Installed library</segtitle>
<variablelist><bridgehead renderas="sect3">Short Descriptions</bridgehead>
<?dbfo list-presentation="list"?>
<?dbhtml list-presentation="table"?>
<seglistitem>
<seg>tclsh (link to tclsh8.4) and tclsh8.4</seg>
<seg>libtcl8.4.so</seg>
</seglistitem>
</segmentedlist>
<varlistentry id="tclsh8.4">
<term><command>tclsh8.4</command></term>
<listitem>
<para>The Tcl command shell</para>
<indexterm zone="ch-tools-tcl tclsh8.4"><primary sortas="b-tclsh8.4">tclsh8.4</primary></indexterm>
</listitem>
</varlistentry>
<variablelist>
<bridgehead renderas="sect3">Short Descriptions</bridgehead>
<?dbfo list-presentation="list"?>
<?dbhtml list-presentation="table"?>
<varlistentry id="tclsh">
<term><command>tclsh</command></term>
<listitem>
<para>A link to tclsh8.4</para>
<indexterm zone="ch-tools-tcl tclsh"><primary sortas="b-tclsh">tclsh</primary></indexterm>
</listitem>
</varlistentry>
<varlistentry id="tclsh8.4">
<term><command>tclsh8.4</command></term>
<listitem>
<para>The Tcl command shell</para>
<indexterm zone="ch-tools-tcl tclsh8.4">
<primary sortas="b-tclsh8.4">tclsh8.4</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="libtcl8.4.so">
<term><filename class="libraryfile">libtcl8.4.so</filename></term>
<listitem>
<para>The Tcl library</para>
<indexterm zone="ch-tools-tcl libtcl8.4.so"><primary sortas="c-libtcl8.4.so">libtcl8.4.so</primary></indexterm>
</listitem>
</varlistentry>
</variablelist>
<varlistentry id="tclsh">
<term><command>tclsh</command></term>
<listitem>
<para>A link to tclsh8.4</para>
<indexterm zone="ch-tools-tcl tclsh">
<primary sortas="b-tclsh">tclsh</primary>
</indexterm>
</listitem>
</varlistentry>
</sect2>
<varlistentry id="libtcl8.4.so">
<term><filename class="libraryfile">libtcl8.4.so</filename></term>
<listitem>
<para>The Tcl library</para>
<indexterm zone="ch-tools-tcl libtcl8.4.so">
<primary sortas="c-libtcl8.4.so">libtcl8.4.so</primary>
</indexterm>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>

View File

@ -1,52 +1,69 @@
<?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-texinfo" role="wrap">
<title>Texinfo-&texinfo-version;</title>
<?dbhtml filename="texinfo.html"?>
<?dbhtml filename="texinfo.html"?>
<indexterm zone="ch-tools-texinfo">
<primary sortas="a-Texinfo">Texinfo</primary>
<secondary>tools</secondary></indexterm>
<title>Texinfo-&texinfo-version;</title>
<sect2 role="package"><title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/texinfo.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<indexterm zone="ch-tools-texinfo">
<primary sortas="a-Texinfo">Texinfo</primary>
<secondary>tools</secondary>
</indexterm>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem><seg>0.2 SBU</seg><seg>14.7 MB</seg></seglistitem>
</segmentedlist>
<sect2 role="package">
<title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/texinfo.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/texinfo.xml"
xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
</sect2>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<sect2 role="installation">
<title>Installation of Texinfo</title>
<seglistitem>
<seg>0.2 SBU</seg>
<seg>14.7 MB</seg>
</seglistitem>
</segmentedlist>
<para>Prepare Texinfo for compilation:</para>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/texinfo.xml"
xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
</sect2>
<sect2 role="installation">
<title>Installation of Texinfo</title>
<para>Prepare Texinfo for compilation:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>To test the results, issue: <userinput>make check</userinput>.</para>
<para>To test the results, issue:
<userinput>make check</userinput>.</para>
<para>Install the package:</para>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect2>
<sect2 role="content"><title/>
<para>Details on this package are located in <xref
linkend="contents-texinfo" role="."/></para>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-texinfo" role="."/></para>
</sect2>
</sect1>

View File

@ -1,225 +1,218 @@
<?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-toolchaintechnotes">
<title>Toolchain Technical Notes</title>
<?dbhtml filename="toolchaintechnotes.html"?>
<?dbhtml filename="toolchaintechnotes.html"?>
<para>This section explains some of the rationale and technical
details behind the overall build method. It is not essential to
immediately understand everything in this section. Most of this
information will be clearer after performing an actual build. This
section can be referred back to at any time during the process.</para>
<title>Toolchain Technical Notes</title>
<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
provide a temporary environment that can be chrooted into and from which can be
produced a clean, trouble-free build of the target LFS system in <xref
linkend="chapter-building-system"/>. Along the way, we separate the new system
from the host system as much as possible, and in doing so, build a
self-contained and self-hosted toolchain. It should be noted that the build
process has been designed to minimize the risks for new readers and provide
maximum educational value at the same time.</para>
<para>This section explains some of the rationale and technical details
behind the overall build method. It is not essential to immediately
understand everything in this section. Most of this information will be
clearer after performing an actual build. This section can be referred
back to at any time during the process.</para>
<important>
<para>Before continuing, be aware of the name of the working platform,
often referred to as the target triplet. Many times, the target
triplet will probably be <emphasis>i686-pc-linux-gnu</emphasis>. A
simple way to determine the name of the target triplet is to run the
<command>config.guess</command> script that comes with the source for
many packages. Unpack the Binutils sources and run the script:
<userinput>./config.guess</userinput> and note the output.</para>
<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
provide a temporary environment that can be chrooted into and from which can be
produced a clean, trouble-free build of the target LFS system in <xref
linkend="chapter-building-system"/>. Along the way, we separate the new system
from the host system as much as possible, and in doing so, build a
self-contained and self-hosted toolchain. It should be noted that the build
process has been designed to minimize the risks for new readers and provide
maximum educational value at the same time.</para>
<para>Also be aware of the name of the platform's dynamic linker,
often referred to as the dynamic loader (not to be confused with the
standard linker <command>ld</command> that is part of Binutils). The
dynamic linker provided by Glibc finds and loads the shared libraries
needed by a program, prepares the program to run, and then runs it.
The name of the dynamic linker will usually be
<filename class="libraryfile">ld-linux.so.2</filename>. On platforms that are less
prevalent, the name might be <filename class="libraryfile">ld.so.1</filename>,
and newer 64 bit platforms might be named something else entirely. The name of
the platform's dynamic linker can be determined by looking in the
<filename class="directory">/lib</filename> directory on the host
system. A sure-fire way to determine the name is to inspect a random
binary from the host system by running: <userinput>readelf -l &lt;name
of binary&gt; | grep interpreter</userinput> and noting the output.
The authoritative reference covering all platforms is in the
<filename>shlib-versions</filename> file in the root of the Glibc
source tree.</para>
</important>
<important>
<para>Before continuing, be aware of the name of the working platform,
often referred to as the target triplet. Many times, the target
triplet will probably be <emphasis>i686-pc-linux-gnu</emphasis>. A
simple way to determine the name of the target triplet is to run the
<command>config.guess</command> script that comes with the source for
many packages. Unpack the Binutils sources and run the script:
<userinput>./config.guess</userinput> and note the output.</para>
<para>Some key technical points of how the <xref linkend="chapter-temporary-tools"/> build
method works:</para>
<para>Also be aware of the name of the platform's dynamic linker, often
referred to as the dynamic loader (not to be confused with the standard
linker <command>ld</command> that is part of Binutils). The dynamic linker
provided by Glibc finds and loads the shared libraries needed by a program,
prepares the program to run, and then runs it. The name of the dynamic
linker will usually be <filename class="libraryfile">ld-linux.so.2</filename>.
On platforms that are less prevalent, the name might be <filename
class="libraryfile">ld.so.1</filename>, and newer 64 bit platforms might
be named something else entirely. The name of the platform's dynamic linker
can be determined by looking in the <filename class="directory">/lib</filename>
directory on the host system. A sure-fire way to determine the name is to
inspect a random binary from the host system by running:
<userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>
and noting the output. The authoritative reference covering all platforms
is in the <filename>shlib-versions</filename> file in the root of the Glibc
source tree.</para>
</important>
<itemizedlist>
<listitem><para>The process is similar in principle to
cross-compiling, whereby tools installed in the same prefix work in
cooperation, and thus utilize a little GNU
<quote>magic</quote></para></listitem>
<para>Some key technical points of how the <xref
linkend="chapter-temporary-tools"/> build method works:</para>
<listitem><para>Careful manipulation of the standard linker's library
search path ensures programs are linked only against chosen
libraries</para></listitem>
<itemizedlist>
<listitem>
<para>The process is similar in principle to cross-compiling, whereby
tools installed in the same prefix work in cooperation, and thus utilize
a little GNU <quote>magic</quote></para>
</listitem>
<listitem>
<para>Careful manipulation of the standard linker's library search path
ensures programs are linked only against chosen libraries</para>
</listitem>
<listitem>
<para>Careful manipulation of <command>gcc</command>'s
<filename>specs</filename> file tells the compiler which target dynamic
linker will be used</para>
</listitem>
</itemizedlist>
<listitem><para>Careful manipulation of <command>gcc</command>'s
<filename>specs</filename> file tells the compiler which target dynamic
linker will be used</para></listitem>
</itemizedlist>
<para>Binutils is installed first because the <command>configure</command>
runs of both GCC and Glibc perform various feature tests on the assembler
and linker to determine which software features to enable or disable. This
is more important than one might first realize. An incorrectly configured
GCC or Glibc can result in a subtly broken toolchain, where the impact of
such breakage might not show up until near the end of the build of an
entire distribution. A test suite failure will usually highlight this error
before too much additional work is performed.</para>
<para>Binutils is installed first because the
<command>configure</command> runs of both GCC and Glibc perform
various feature tests on the assembler and linker to determine which
software features to enable or disable. This is more important than
one might first realize. An incorrectly configured GCC or Glibc can
result in a subtly broken toolchain, where the impact of such breakage
might not show up until near the end of the build of an entire
distribution. A test suite failure will usually highlight this error
before too much additional work is performed.</para>
<para>Binutils installs its assembler and linker in two locations,
<filename class="directory">/tools/bin</filename> and <filename
class="directory">/tools/$TARGET_TRIPLET/bin</filename>. The tools in one
location are hard linked to the other. An important facet of the linker is
its library search order. Detailed information can be obtained from
<command>ld</command> by passing it the <parameter>--verbose</parameter>
flag. For example, an <userinput>ld --verbose | grep SEARCH</userinput>
will illustrate the current search paths and their order. It shows which
files are linked by <command>ld</command> by compiling a dummy program and
passing the <parameter>--verbose</parameter> switch to the linker. For example,
<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
will show all the files successfully opened during the linking.</para>
<para>Binutils installs its assembler and linker in two locations,
<filename class="directory">/tools/bin</filename> and <filename
class="directory">/tools/$TARGET_TRIPLET/bin</filename>. The tools in
one location are hard linked to the other. An important facet of the
linker is its library search order. Detailed information can be
obtained from <command>ld</command> by passing it the
<parameter>--verbose</parameter> flag. For example, an <userinput>ld
--verbose | grep SEARCH</userinput> will illustrate the current search
paths and their order. It shows which files are linked by
<command>ld</command> by compiling a dummy program and passing the
<parameter>--verbose</parameter> switch to the linker. For example,
<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep
succeeded</userinput> will show all the files successfully opened
during the linking.</para>
<para>The next package installed is GCC. An example of what can be
seen during its run of <command>configure</command> is:</para>
<para>The next package installed is GCC. An example of what can be
seen during its run of <command>configure</command> is:</para>
<screen><computeroutput>checking what assembler to use...
/tools/i686-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen>
<para>This is important for the reasons mentioned above. It also
demonstrates that GCC's configure script does not search the PATH
directories to find which tools to use. However, during the actual
operation of <command>gcc</command> itself, the same
search paths are not necessarily used. To find out which standard
linker <command>gcc</command> will use, run: <userinput>gcc
-print-prog-name=ld</userinput>.</para>
<para>This is important for the reasons mentioned above. It also demonstrates
that GCC's configure script does not search the PATH directories to find which
tools to use. However, during the actual operation of <command>gcc</command>
itself, the same search paths are not necessarily used. To find out which
standard linker <command>gcc</command> will use, run:
<userinput>gcc -print-prog-name=ld</userinput>.</para>
<para>Detailed information can be obtained from <command>gcc</command>
by passing it the <parameter>-v</parameter> command line option while
compiling a dummy program. For example, <userinput>gcc -v
dummy.c</userinput> will show detailed information about the
preprocessor, compilation, and assembly stages, including
<command>gcc</command>'s included search paths and their order.</para>
<para>Detailed information can be obtained from <command>gcc</command> by
passing it the <parameter>-v</parameter> command line option while compiling
a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
detailed information about the preprocessor, compilation, and assembly stages,
including <command>gcc</command>'s included search paths and their order.</para>
<para>The next package installed is Glibc. The most important
considerations for building Glibc are the compiler, binary tools, and
kernel headers. The compiler is generally not an issue since Glibc
will always use the <command>gcc</command> found in a
<envar>PATH</envar> directory.
The binary tools and kernel headers can be a bit more complicated.
Therefore, take no risks and use the available configure switches to
enforce the correct selections. After the run of
<command>configure</command>, check the contents of the
<filename>config.make</filename> file in the <filename
class="directory">glibc-build</filename> directory for all important
details. Note the use of <parameter>CC="gcc -B/tools/bin/"</parameter>
to control which binary tools are used and the use of the
<parameter>-nostdinc</parameter> and <parameter>-isystem</parameter>
flags to control the compiler's include search path. These items
highlight an important aspect of the Glibc package&mdash;it is very
self-sufficient in terms of its build machinery and generally does not
rely on toolchain defaults.</para>
<para>The next package installed is Glibc. The most important considerations
for building Glibc are the compiler, binary tools, and kernel headers. The
compiler is generally not an issue since Glibc will always use the
<command>gcc</command> found in a <envar>PATH</envar> directory. The binary
tools and kernel headers can be a bit more complicated. Therefore, take no
risks and use the available configure switches to enforce the correct
selections. After the run of <command>configure</command>, check the contents
of the <filename>config.make</filename> file in the <filename
class="directory">glibc-build</filename> directory for all important details.
Note the use of <parameter>CC="gcc -B/tools/bin/"</parameter> to control which
binary tools are used and the use of the <parameter>-nostdinc</parameter>
and <parameter>-isystem</parameter> flags to control the compiler's include
search path. These items highlight an important aspect of the Glibc
package&mdash;it is very self-sufficient in terms of its build machinery and
generally does not rely on toolchain defaults.</para>
<para>After the Glibc installation, make some adjustments to ensure
that searching and linking take place only within the <filename
class="directory">/tools</filename> prefix. Install an adjusted
<command>ld</command>, which has a hard-wired search path limited to
<filename class="directory">/tools/lib</filename>. Then amend
<command>gcc</command>'s specs file to point to the new dynamic linker
in <filename class="directory">/tools/lib</filename>. This last step
is vital to the whole process. As mentioned above, a hard-wired path
to a dynamic linker is embedded into every Executable and Link Format
(ELF)-shared executable. This can be inspected by running:
<userinput>readelf -l &lt;name of binary&gt; | grep
interpreter</userinput>. Amending gcc's specs file
ensures that every program compiled from here through the end of this
chapter will use the new dynamic linker in <filename
class="directory">/tools/lib</filename>.</para>
<para>After the Glibc installation, make some adjustments to ensure that
searching and linking take place only within the <filename
class="directory">/tools</filename> prefix. Install an adjusted
<command>ld</command>, which has a hard-wired search path limited to
<filename class="directory">/tools/lib</filename>. Then amend
<command>gcc</command>'s specs file to point to the new dynamic linker in
<filename class="directory">/tools/lib</filename>. This last step is vital
to the whole process. As mentioned above, a hard-wired path to a dynamic
linker is embedded into every Executable and Link Format (ELF)-shared
executable. This can be inspected by running:
<userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>.
Amending gcc's specs file ensures that every program compiled from here
through the end of this chapter will use the new dynamic linker in
<filename class="directory">/tools/lib</filename>.</para>
<para>The need to use the new dynamic linker is also the reason why
the Specs patch is applied for the second pass of GCC. Failure to do
so will result in the GCC programs themselves having the name of the
dynamic linker from the host system's <filename
class="directory">/lib</filename> directory embedded into them, which
would defeat the goal of getting away from the host.</para>
<para>The need to use the new dynamic linker is also the reason why
the Specs patch is applied for the second pass of GCC. Failure to do
so will result in the GCC programs themselves having the name of the
dynamic linker from the host system's <filename
class="directory">/lib</filename> directory embedded into them, which
would defeat the goal of getting away from the host.</para>
<para>During the second pass of Binutils, we are able to utilize the
<parameter>--with-lib-path</parameter> configure switch to control
<command>ld</command>'s library search path. From this point onwards,
the core toolchain is self-contained and self-hosted. The remainder of
the <xref linkend="chapter-temporary-tools"/> packages all build
against the new Glibc in <filename
class="directory">/tools</filename>.</para>
<para>During the second pass of Binutils, we are able to utilize the
<parameter>--with-lib-path</parameter> configure switch to control
<command>ld</command>'s library search path. From this point onwards,
the core toolchain is self-contained and self-hosted. The remainder of
the <xref linkend="chapter-temporary-tools"/> packages all build against
the new Glibc in <filename class="directory">/tools</filename>.</para>
<para>Upon entering the chroot environment in <xref
linkend="chapter-building-system"/>, the first major package to be
installed is Glibc, due to its self-sufficient nature mentioned above.
Once this Glibc is installed into <filename
class="directory">/usr</filename>, perform a quick changeover of the
toolchain defaults, then proceed in building the rest of the target
LFS system.</para>
<para>Upon entering the chroot environment in <xref
linkend="chapter-building-system"/>, the first major package to be
installed is Glibc, due to its self-sufficient nature mentioned above.
Once this Glibc is installed into <filename
class="directory">/usr</filename>, perform a quick changeover of the
toolchain defaults, then proceed in building the rest of the target
LFS system.</para>
<!-- Removed as part of the fix for bug 1061 - we no longer build pass1
packages statically, therefore this explanation isn't required -->
<!-- Removed as part of the fix for bug 1061 - we no longer build pass1
packages statically, therefore this explanation isn't required -->
<!--<sect2>
<title>Notes on Static Linking</title>
<!--<sect2>
<title>Notes on Static Linking</title>
<para>Besides their specific task, most programs have to perform many
common and sometimes trivial operations. These include allocating
memory, searching directories, reading and writing files, string
handling, pattern matching, arithmetic, and other tasks. Instead of
obliging each program to reinvent the wheel, the GNU system provides
all these basic functions in ready-made libraries. The major library
on any Linux system is Glibc.</para>
<para>Besides their specific task, most programs have to perform many
common and sometimes trivial operations. These include allocating
memory, searching directories, reading and writing files, string
handling, pattern matching, arithmetic, and other tasks. Instead of
obliging each program to reinvent the wheel, the GNU system provides
all these basic functions in ready-made libraries. The major library
on any Linux system is Glibc.</para>
<para>There are two primary ways of linking the functions from a
library to a program that uses them&mdash;statically or dynamically. When
a program is linked statically, the code of the used functions is
included in the executable, resulting in a rather bulky program. When
a program is dynamically linked, it includes a reference to the
dynamic linker, the name of the library, and the name of the function,
resulting in a much smaller executable. A third option is to use the
programming interface of the dynamic linker (see <filename>dlopen(3)</filename>
for more information).</para>
<para>There are two primary ways of linking the functions from a
library to a program that uses them&mdash;statically or dynamically. When
a program is linked statically, the code of the used functions is
included in the executable, resulting in a rather bulky program. When
a program is dynamically linked, it includes a reference to the
dynamic linker, the name of the library, and the name of the function,
resulting in a much smaller executable. A third option is to use the
programming interface of the dynamic linker (see <filename>dlopen(3)</filename>
for more information).</para>
<para>Dynamic linking is the default on Linux and has three major
advantages over static linking. First, only one copy of the executable
library code is needed on the hard disk, instead of having multiple
copies of the same code included in several programs, thus saving
disk space. Second, when several programs use the same library
function at the same time, only one copy of the function's code is
required in core, thus saving memory space. Third, when a library
function gets a bug fixed or is otherwise improved, only the one
library needs to be recompiled instead of recompiling all programs
that make use of the improved function.</para>
<para>Dynamic linking is the default on Linux and has three major
advantages over static linking. First, only one copy of the executable
library code is needed on the hard disk, instead of having multiple
copies of the same code included in several programs, thus saving
disk space. Second, when several programs use the same library
function at the same time, only one copy of the function's code is
required in core, thus saving memory space. Third, when a library
function gets a bug fixed or is otherwise improved, only the one
library needs to be recompiled instead of recompiling all programs
that make use of the improved function.</para>
<para>If dynamic linking has several advantages, why then do we
statically link the first two packages in this chapter? The reasons
are threefold&mdash;historical, educational, and technical. The
historical reason is that earlier versions of LFS statically linked
every program in this chapter. Educationally, knowing the difference
between static and dynamic linking is useful. The technical benefit is
a gained element of independence from the host, meaning that those
programs can be used independently of the host system. However, it is
worth noting that an overall successful LFS build can still be
achieved when the first two packages are built dynamically.</para>
<para>If dynamic linking has several advantages, why then do we
statically link the first two packages in this chapter? The reasons
are threefold&mdash;historical, educational, and technical. The
historical reason is that earlier versions of LFS statically linked
every program in this chapter. Educationally, knowing the difference
between static and dynamic linking is useful. The technical benefit is
a gained element of independence from the host, meaning that those
programs can be used independently of the host system. However, it is
worth noting that an overall successful LFS build can still be
achieved when the first two packages are built dynamically.</para>
</sect2>-->
</sect2>-->
</sect1>

View File

@ -1,63 +1,80 @@
<?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-util-linux" role="wrap">
<title>Util-linux-&util-linux-version;</title>
<?dbhtml filename="util-linux.html"?>
<?dbhtml filename="util-linux.html"?>
<indexterm zone="ch-tools-util-linux">
<primary sortas="a-Util-linux">Util-linux</primary>
<secondary>tools</secondary></indexterm>
<title>Util-linux-&util-linux-version;</title>
<sect2 role="package"><title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/util-linux.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<indexterm zone="ch-tools-util-linux">
<primary sortas="a-Util-linux">Util-linux</primary>
<secondary>tools</secondary>
</indexterm>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem><seg>0.2 SBU</seg><seg>8.9 MB</seg></seglistitem>
</segmentedlist>
<sect2 role="package">
<title/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/util-linux.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/util-linux.xml"
xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
</sect2>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<sect2 role="installation">
<title>Installation of Util-linux</title>
<seglistitem>
<seg>0.2 SBU</seg>
<seg>8.9 MB</seg>
</seglistitem>
</segmentedlist>
<para>Util-linux does not use the freshly installed headers and libraries from
the <filename class="directory">/tools</filename> directory by default. This is
fixed by altering the configure script:</para>
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
href="../chapter06/util-linux.xml"
xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
</sect2>
<sect2 role="installation">
<title>Installation of Util-linux</title>
<para>Util-linux does not use the freshly installed headers and libraries
from the <filename class="directory">/tools</filename> directory by default.
This is fixed by altering the configure script:</para>
<screen><userinput>sed -i 's@/usr/include@/tools/include@g' configure</userinput></screen>
<para>Prepare Util-linux for compilation:</para>
<para>Prepare Util-linux for compilation:</para>
<screen><userinput>./configure</userinput></screen>
<para>Compile some support routines:</para>
<para>Compile some support routines:</para>
<screen><userinput>make -C lib</userinput></screen>
<para>Only a few of the utilities contained in this package need to be
built:</para>
<para>Only a few of the utilities contained in this package need to be
built:</para>
<screen><userinput>make -C mount mount umount
make -C text-utils more</userinput></screen>
<para>This package does not come with a test suite.</para>
<para>This package does not come with a test suite.</para>
<para>Copy these programs to the temporary tools directory:</para>
<para>Copy these programs to the temporary tools directory:</para>
<screen><userinput>cp mount/{,u}mount text-utils/more /tools/bin</userinput></screen>
</sect2>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-utillinux" role="."/></para>
</sect2>
<sect2 role="content"><title/>
<para>Details on this package are located in <xref
linkend="contents-utillinux" role="."/></para>
</sect2>
</sect1>