Merging caption and installation sections for all packages in chapters 5 and 6.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3052 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud 2003-11-01 22:31:50 +00:00
parent 0b400add2b
commit 73aedd1d35
207 changed files with 3282 additions and 3401 deletions

View File

@ -1,35 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bash</title>
<para>Bash contains several known bugs. Fix these with the following
patch:</para>
<screen><userinput>patch -Np1 -i ../&bash-patch;</userinput></screen>
<para>Now prepare Bash for compilation:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the program:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make tests</userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
<para>And make a link for the programs that use <userinput>sh</userinput>
for a shell:</para>
<screen><userinput>ln -s bash /tools/bin/sh</userinput></screen>
</sect2>

View File

@ -7,7 +7,41 @@ Estimated required disk space: &bash-compsize-tools;</screen>
&aa-bash-shortdesc;
&aa-bash-dep;
&c5-bash-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bash</title>
<para>Bash contains several known bugs. Fix these with the following
patch:</para>
<screen><userinput>patch -Np1 -i ../&bash-patch;</userinput></screen>
<para>Now prepare Bash for compilation:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the program:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make tests</userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
<para>And make a link for the programs that use <userinput>sh</userinput>
for a shell:</para>
<screen><userinput>ln -s bash /tools/bin/sh</userinput></screen>
</sect2>
</sect1>

View File

@ -1,106 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Binutils</title>
<para>It is important that Binutils be the first package to get compiled,
because both Glibc and GCC perform various tests on the available linker and
assembler to determine which of their own features to enable.</para>
<note><para>Even though Binutils is an important toolchain package, we are not
going to run the test suite at this early stage. First, the test suite framework
is not yet in place and second, the programs from this first pass will soon be
overwritten by those installed in the second pass.</para></note>
<para>This package is known to behave badly when you have changed its default
optimization flags (including the -march and -mcpu options). Therefore, if
you have defined any environment variables that override default
optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
modifying them when building Binutils.</para>
<para>The Binutils documentation recommends building Binutils outside of the
source directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../binutils-build
cd ../binutils-build</userinput></screen>
<note><para>If you want the SBU values listed in the rest of the book to be of
any use, you will have to measure the time it takes to build this package. To
achieve this easily, you could do something like:
<userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ... &amp;&amp; make install; }</userinput>.</para></note>
<para>Now prepare Binutils for compilation:</para>
<screen><userinput>../binutils-&binutils-version;/configure \
&nbsp;&nbsp;&nbsp;&nbsp;--prefix=/tools --disable-nls</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--prefix=/tools</userinput>: This tells the
configure script to prepare to install the Binutils programs in the
<filename>/tools</filename> directory.</para></listitem>
<listitem><para><userinput>--disable-nls</userinput>: This disables
internationalization (a word often shortened to i18n). We don't need this
for our static programs and <emphasis>nls</emphasis> often causes problems
when linking statically.</para></listitem>
</itemizedlist>
<para>Continue with compiling the package:</para>
<screen><userinput>make configure-host
make LDFLAGS="-all-static"</userinput></screen>
<para>The meaning of the make options:</para>
<itemizedlist>
<listitem><para><userinput>configure-host</userinput>: This forces all the
subdirectories to be configured immediately. A statically linked build will
fail without it. We therefore use this option to work around the
problem.</para></listitem>
<listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the
linker that all the Binutils programs should be linked statically. However,
strictly speaking, <userinput>"-all-static"</userinput> is first passed to the
<emphasis>libtool</emphasis> program which then passes
<userinput>"-static"</userinput> on to the linker.</para></listitem>
</itemizedlist>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Now prepare the linker for the "locking in" of Glibc later on:</para>
<screen><userinput>make -C ld clean
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
<para>The meaning of the make options:</para>
<itemizedlist>
<listitem><para><userinput>-C ld clean</userinput>: This tells the make program
to remove all the compiled files, but only in the <filename>ld</filename>
subdirectory.</para></listitem>
<listitem><para><userinput>-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput>:
This option rebuilds everything in the <filename>ld</filename> subdirectory.
Specifying the LIB_PATH makefile variable on the command line allows us to
override the default value and have it point to our temporary tools location.
The value of this variable specifies the linker's default library search path.
You'll see how this preparation is used later on in the
chapter.</para></listitem>
</itemizedlist>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
<warning><para>Do not yet remove the Binutils build and source directories. You
will need them again in their current state a bit further on in this
chapter.</para></warning>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
</sect2>

View File

@ -7,7 +7,112 @@ Estimated required disk space: &binutils-compsize-tools-pass1;</screen>
&aa-binutils-shortdesc;
&aa-binutils-dep;
&c5-binutils-pass1-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Binutils</title>
<para>It is important that Binutils be the first package to get compiled,
because both Glibc and GCC perform various tests on the available linker and
assembler to determine which of their own features to enable.</para>
<note><para>Even though Binutils is an important toolchain package, we are not
going to run the test suite at this early stage. First, the test suite framework
is not yet in place and second, the programs from this first pass will soon be
overwritten by those installed in the second pass.</para></note>
<para>This package is known to behave badly when you have changed its default
optimization flags (including the -march and -mcpu options). Therefore, if
you have defined any environment variables that override default
optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
modifying them when building Binutils.</para>
<para>The Binutils documentation recommends building Binutils outside of the
source directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../binutils-build
cd ../binutils-build</userinput></screen>
<note><para>If you want the SBU values listed in the rest of the book to be of
any use, you will have to measure the time it takes to build this package. To
achieve this easily, you could do something like:
<userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ... &amp;&amp; make install; }</userinput>.</para></note>
<para>Now prepare Binutils for compilation:</para>
<screen><userinput>../binutils-&binutils-version;/configure \
&nbsp;&nbsp;&nbsp;&nbsp;--prefix=/tools --disable-nls</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--prefix=/tools</userinput>: This tells the
configure script to prepare to install the Binutils programs in the
<filename>/tools</filename> directory.</para></listitem>
<listitem><para><userinput>--disable-nls</userinput>: This disables
internationalization (a word often shortened to i18n). We don't need this
for our static programs and <emphasis>nls</emphasis> often causes problems
when linking statically.</para></listitem>
</itemizedlist>
<para>Continue with compiling the package:</para>
<screen><userinput>make configure-host
make LDFLAGS="-all-static"</userinput></screen>
<para>The meaning of the make options:</para>
<itemizedlist>
<listitem><para><userinput>configure-host</userinput>: This forces all the
subdirectories to be configured immediately. A statically linked build will
fail without it. We therefore use this option to work around the
problem.</para></listitem>
<listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the
linker that all the Binutils programs should be linked statically. However,
strictly speaking, <userinput>"-all-static"</userinput> is first passed to the
<emphasis>libtool</emphasis> program which then passes
<userinput>"-static"</userinput> on to the linker.</para></listitem>
</itemizedlist>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Now prepare the linker for the "locking in" of Glibc later on:</para>
<screen><userinput>make -C ld clean
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
<para>The meaning of the make options:</para>
<itemizedlist>
<listitem><para><userinput>-C ld clean</userinput>: This tells the make program
to remove all the compiled files, but only in the <filename>ld</filename>
subdirectory.</para></listitem>
<listitem><para><userinput>-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput>:
This option rebuilds everything in the <filename>ld</filename> subdirectory.
Specifying the LIB_PATH makefile variable on the command line allows us to
override the default value and have it point to our temporary tools location.
The value of this variable specifies the linker's default library search path.
You'll see how this preparation is used later on in the
chapter.</para></listitem>
</itemizedlist>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
<warning><para>Do not yet remove the Binutils build and source directories. You
will need them again in their current state a bit further on in this
chapter.</para></warning>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
</sect2>
</sect1>

View File

@ -1,68 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Re-installation of Binutils</title>
<para>Create a separate build directory again:</para>
<screen><userinput>mkdir ../binutils-build
cd ../binutils-build</userinput></screen>
<para>Now prepare Binutils to be compiled:</para>
<screen><userinput>../binutils-&binutils-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-shared --with-lib-path=/tools/lib</userinput></screen>
<para>The meaning of the new configure option:</para>
<itemizedlist>
<listitem><para><userinput>--with-lib-path=/tools/lib</userinput>: This tells
the configure script to specify the default library search path. We don't want
the library search path to contain library directories from the host
system.</para></listitem>
</itemizedlist>
<para>Before starting to build Binutils, remember to unset any environment
variables that override the default optimization flags.</para>
<para>Compile the package:</para>
<screen><userinput>make </userinput></screen>
<note><para>It's worth pointing out that running the Binutils test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>Test the results (there should be no unexpected failures here, expected
failures are fine):</para>
<screen><userinput>make check</userinput></screen>
<para>Unfortunately, there is no easy way to view the test results summary like
there was for the previous GCC package. However, if a failure occurs here, it
should be easy to spot. The output shown will contain something like:</para>
<blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Now prepare Binutils for the re-adjusting of the toolchain in the next
chapter:</para>
<screen><userinput>make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib</userinput></screen>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
<warning><para>Do not yet remove the Binutils source and build directories.
We'll need these directories again in the next chapter in the state they are in
now.</para></warning>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
</sect2>

View File

@ -5,7 +5,74 @@
<screen>Estimated build time: &binutils-time-tools-pass2;
Estimated required disk space: &binutils-compsize-tools-pass2;</screen>
&c5-binutils-pass2-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Re-installation of Binutils</title>
<para>Create a separate build directory again:</para>
<screen><userinput>mkdir ../binutils-build
cd ../binutils-build</userinput></screen>
<para>Now prepare Binutils to be compiled:</para>
<screen><userinput>../binutils-&binutils-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-shared --with-lib-path=/tools/lib</userinput></screen>
<para>The meaning of the new configure option:</para>
<itemizedlist>
<listitem><para><userinput>--with-lib-path=/tools/lib</userinput>: This tells
the configure script to specify the default library search path. We don't want
the library search path to contain library directories from the host
system.</para></listitem>
</itemizedlist>
<para>Before starting to build Binutils, remember to unset any environment
variables that override the default optimization flags.</para>
<para>Compile the package:</para>
<screen><userinput>make </userinput></screen>
<note><para>It's worth pointing out that running the Binutils test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>Test the results (there should be no unexpected failures here, expected
failures are fine):</para>
<screen><userinput>make check</userinput></screen>
<para>Unfortunately, there is no easy way to view the test results summary like
there was for the previous GCC package. However, if a failure occurs here, it
should be easy to spot. The output shown will contain something like:</para>
<blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Now prepare Binutils for the re-adjusting of the toolchain in the next
chapter:</para>
<screen><userinput>make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib</userinput></screen>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
<warning><para>Do not yet remove the Binutils source and build directories.
We'll need these directories again in the next chapter in the state they are in
now.</para></warning>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>
</sect2>
</sect1>

View File

@ -1,12 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bzip2</title>
<para>The Bzip2 package doesn't contain a <userinput>configure</userinput>
script. Compile and install it with a straightforward:</para>
<screen><userinput>make PREFIX=/tools install</userinput></screen>
</sect2>

View File

@ -7,7 +7,18 @@ Estimated required disk space: &bzip2-compsize-tools;</screen>
&aa-bzip2-shortdesc;
&aa-bzip2-dep;
&c5-bzip2-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bzip2</title>
<para>The Bzip2 package doesn't contain a <userinput>configure</userinput>
script. Compile and install it with a straightforward:</para>
<screen><userinput>make PREFIX=/tools install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,34 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Coreutils</title>
<para>Prepare Coreutils to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make RUN_EXPENSIVE_TESTS=yes check</userinput></screen>
<para>The meaning of the make option:</para>
<itemizedlist>
<listitem><para><userinput>RUN_EXPENSIVE_TESTS=yes</userinput>: This tells the
test suite to run several additional tests that are considered relatively
expensive on some platforms. However, they are generally not a problem on
Linux.</para></listitem>
</itemizedlist>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,40 @@ Estimated required disk space: &coreutils-compsize-tools;</screen>
&aa-coreutils-shortdesc;
&aa-coreutils-dep;
&c5-coreutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Coreutils</title>
<para>Prepare Coreutils to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make RUN_EXPENSIVE_TESTS=yes check</userinput></screen>
<para>The meaning of the make option:</para>
<itemizedlist>
<listitem><para><userinput>RUN_EXPENSIVE_TESTS=yes</userinput>: This tells the
test suite to run several additional tests that are considered relatively
expensive on some platforms. However, they are generally not a problem on
Linux.</para></listitem>
</itemizedlist>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,15 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of DejaGnu</title>
<para>Prepare DejaGnu to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Build and install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,21 @@ Estimated required disk space: &dejagnu-compsize-tools;</screen>
&aa-dejagnu-shortdesc;
&aa-dejagnu-dep;
&c5-dejagnu-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of DejaGnu</title>
<para>Prepare DejaGnu to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Build and install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,19 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Diffutils</title>
<para>Prepare Diffutils to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,25 @@ Estimated required disk space: &diffutils-compsize-tools;</screen>
&aa-diffutils-shortdesc;
&aa-diffutils-dep;
&c5-diffutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Diffutils</title>
<para>Prepare Diffutils to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,57 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Expect</title>
<para>First apply a patch:</para>
<screen><userinput>patch -Np1 -i ../&expect-patch;</userinput></screen>
<para>This fixes a bug in Expect that can result in bogus failures during the
GCC test suite run.</para>
<para>Now prepare Expect to be compiled:</para>
<screen><userinput>./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--with-tcl=/tools/lib</userinput>: This ensures that
the configure script finds the Tcl installation in our temporary tools location.
We don't want it to find an existing one that may possibly reside on the host
system.</para></listitem>
<listitem><para><userinput>--with-x=no</userinput>: This tells the configure
script not to search for Tk (the Tcl GUI component) or the X Window System
libraries, both of which may possibly reside on the host system.</para></listitem>
</itemizedlist>
<para>Build the package:</para>
<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
are not fully understood. Therefore, test suite failures here are not
surprising, but 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>
<para>And install:</para>
<screen><userinput>make SCRIPTS="" install</userinput></screen>
<para>The meaning of the make option:</para>
<itemizedlist>
<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation of
the supplementary expect scripts which are not needed.</para></listitem>
</itemizedlist>
<para>You can now remove the source directories of both Tcl and Expect.</para>
</sect2>

View File

@ -7,7 +7,63 @@ Estimated required disk space: &expect-compsize-tools;</screen>
&aa-expect-shortdesc;
&aa-expect-dep;
&c5-expect-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Expect</title>
<para>First apply a patch:</para>
<screen><userinput>patch -Np1 -i ../&expect-patch;</userinput></screen>
<para>This fixes a bug in Expect that can result in bogus failures during the
GCC test suite run.</para>
<para>Now prepare Expect to be compiled:</para>
<screen><userinput>./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--with-tcl=/tools/lib</userinput>: This ensures that
the configure script finds the Tcl installation in our temporary tools location.
We don't want it to find an existing one that may possibly reside on the host
system.</para></listitem>
<listitem><para><userinput>--with-x=no</userinput>: This tells the configure
script not to search for Tk (the Tcl GUI component) or the X Window System
libraries, both of which may possibly reside on the host system.</para></listitem>
</itemizedlist>
<para>Build the package:</para>
<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
are not fully understood. Therefore, test suite failures here are not
surprising, but 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>
<para>And install:</para>
<screen><userinput>make SCRIPTS="" install</userinput></screen>
<para>The meaning of the make option:</para>
<itemizedlist>
<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation of
the supplementary expect scripts which are not needed.</para></listitem>
</itemizedlist>
<para>You can now remove the source directories of both Tcl and Expect.</para>
</sect2>
</sect1>

View File

@ -1,24 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installing Findutils</title>
<para>Prepare Findutils to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &findutils-compsize-tools;</screen>
&aa-findutils-shortdesc;
&aa-findutils-dep;
&c5-findutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installing Findutils</title>
<para>Prepare Findutils to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gawk</title>
<para>Prepare Gawk to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &gawk-compsize-tools;</screen>
&aa-gawk-shortdesc;
&aa-gawk-dep;
&c5-gawk-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gawk</title>
<para>Prepare Gawk to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,89 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of GCC</title>
<para>Unpack only the GCC-core tarball, as we won't be needing a C++ compiler
for the moment.</para>
<note><para>Even though GCC is an important toolchain package, we are not
going to run the test suite at this early stage. First, the test suite framework
is not yet in place and second, the programs from this first pass will soon be
overwritten by those installed in the second pass.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Prepare GCC to be compiled:</para>
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-nls --enable-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--with-local-prefix=/tools</userinput>: The
purpose of this switch is to remove <filename>/usr/local/include</filename>
from <userinput>gcc</userinput>'s include search path. This is not absolutely
essential; however, we want to try to minimize the influence of the host
system, thus making this a sensible thing to do.</para></listitem>
<listitem><para><userinput>--enable-shared</userinput>: This switch may
seem counter-intuitive at first. But using it allows the building of
<filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
having <filename>libgcc_eh.a</filename> available ensures that the configure
script for Glibc (the next package we compile) produces the proper results.
Note that the <userinput>gcc</userinput> binaries will still be linked
statically, as this is controlled by the <userinput>-static</userinput>
value of BOOT_LDFLAGS further on.</para></listitem>
<listitem><para><userinput>--enable-languages=c</userinput>: This option
ensures that only the C compiler is built. The option is only needed when you
have downloaded and unpacked the full GCC tarball.</para></listitem>
</itemizedlist>
<para>Continue with compiling the package:</para>
<screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen>
<para>The meaning of the make parameters:</para>
<itemizedlist>
<listitem><para><userinput>BOOT_LDFLAGS="-static"</userinput>: This tells
GCC to link its programs statically.</para></listitem>
<listitem><para><userinput>bootstrap</userinput>: This target doesn't just
compile GCC, but compiles it several times. It uses the programs compiled in
a first round to compile itself a second time, and then again a third time.
It then compares these second and third compiles to make sure it can
reproduce itself flawlessly, which most probably means that it was
compiled correctly.</para></listitem>
</itemizedlist>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>As a finishing touch we'll create the <filename
class="symlink">/tools/bin/cc</filename> symlink. Many programs and
scripts run <userinput>cc</userinput> instead of <userinput>gcc</userinput>,
a thing meant to keep programs generic and therefore usable on all kinds of
Unix systems. Not everybody has the GNU C compiler installed. Simply running
<userinput>cc</userinput> leaves the system administrator free to decide what
C compiler to install, as long as there's a symlink pointing to it:</para>
<screen><userinput>ln -sf gcc /tools/bin/cc</userinput></screen>
</sect2>

View File

@ -7,7 +7,95 @@ Estimated required disk space: &gcc-compsize-tools-pass1;</screen>
&aa-gcc-shortdesc;
&aa-gcc-dep;
&c5-gcc-pass1-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of GCC</title>
<para>Unpack only the GCC-core tarball, as we won't be needing a C++ compiler
for the moment.</para>
<note><para>Even though GCC is an important toolchain package, we are not
going to run the test suite at this early stage. First, the test suite framework
is not yet in place and second, the programs from this first pass will soon be
overwritten by those installed in the second pass.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Prepare GCC to be compiled:</para>
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-nls --enable-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--with-local-prefix=/tools</userinput>: The
purpose of this switch is to remove <filename>/usr/local/include</filename>
from <userinput>gcc</userinput>'s include search path. This is not absolutely
essential; however, we want to try to minimize the influence of the host
system, thus making this a sensible thing to do.</para></listitem>
<listitem><para><userinput>--enable-shared</userinput>: This switch may
seem counter-intuitive at first. But using it allows the building of
<filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
having <filename>libgcc_eh.a</filename> available ensures that the configure
script for Glibc (the next package we compile) produces the proper results.
Note that the <userinput>gcc</userinput> binaries will still be linked
statically, as this is controlled by the <userinput>-static</userinput>
value of BOOT_LDFLAGS further on.</para></listitem>
<listitem><para><userinput>--enable-languages=c</userinput>: This option
ensures that only the C compiler is built. The option is only needed when you
have downloaded and unpacked the full GCC tarball.</para></listitem>
</itemizedlist>
<para>Continue with compiling the package:</para>
<screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen>
<para>The meaning of the make parameters:</para>
<itemizedlist>
<listitem><para><userinput>BOOT_LDFLAGS="-static"</userinput>: This tells
GCC to link its programs statically.</para></listitem>
<listitem><para><userinput>bootstrap</userinput>: This target doesn't just
compile GCC, but compiles it several times. It uses the programs compiled in
a first round to compile itself a second time, and then again a third time.
It then compares these second and third compiles to make sure it can
reproduce itself flawlessly, which most probably means that it was
compiled correctly.</para></listitem>
</itemizedlist>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>As a finishing touch we'll create the <filename
class="symlink">/tools/bin/cc</filename> symlink. Many programs and
scripts run <userinput>cc</userinput> instead of <userinput>gcc</userinput>,
a thing meant to keep programs generic and therefore usable on all kinds of
Unix systems. Not everybody has the GNU C compiler installed. Simply running
<userinput>cc</userinput> leaves the system administrator free to decide what
C compiler to install, as long as there's a symlink pointing to it:</para>
<screen><userinput>ln -sf gcc /tools/bin/cc</userinput></screen>
</sect2>
</sect1>

View File

@ -1,164 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Re-installation of GCC</title>
<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
the new Glibc, and test them properly. One thing to note, however, is that these
test suites are highly dependent on properly functioning pseudo terminals (PTYs)
which are provided by your host distribution. These days, PTYs are most commonly
implemented via the <emphasis>devpts</emphasis> file system. You can quickly
check if your host system is set up correctly in this regard by performing a
simple test:</para>
<screen><userinput>expect -c "spawn ls"</userinput></screen>
<para>If you receive the message:</para>
<blockquote><screen>The system has no more ptys. Ask your system administrator to create more.</screen></blockquote>
<para>Your host distribution is not set up for proper PTY operation. In this
case there is no point in running the test suites for GCC and Binutils until you
are able to resolve the issue. You can consult the LFS Wiki at
<ulink url="http://wiki.linuxfromscratch.org/"/> for more information on how to
get PTYs working.</para>
<para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
same working directory. They will all unfold into a single
<filename>gcc-&gcc-version;/</filename> subdirectory.</para>
<para>First correct one problem and make an essential adjustment:</para>
<screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
<para>The first patch disables the GCC "fixincludes" script. We mentioned this
briefly earlier, but a slightly more in-depth explanation of the fixincludes
process is warranted here. Under normal circumstances, the GCC fixincludes
script scans your system for header files that need to be fixed. It might find
that some Glibc header files on your host system need to be fixed, fix them and
put them in the GCC private include directory. Then, later on in
<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
private include directory would be searched before the system include
directory, resulting in GCC finding the fixed headers from the host system,
which would most likely not match the Glibc version actually used for the LFS
system.</para>
<para>The last patch changes GCC's default location of the dynamic linker
(typically <filename>ld-linux.so.2</filename>). It also removes
<filename class="directory">/usr/include</filename> from GCC's include search
path. Patching now rather than adjusting the specs file after installation
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>
<para>Create a separate build directory again:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Before starting to build GCC, remember to unset any environment
variables that override the default optimization flags.</para>
<para>Now prepare GCC to be compiled:</para>
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-clocale=gnu --enable-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix --enable-__cxa_atexit \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen>
<para>The meaning of the new configure options:</para>
<itemizedlist>
<listitem><para><userinput>--enable-threads=posix</userinput>: This enables
C++ exception handling for multi-threaded code.</para></listitem>
<listitem><para><userinput>--enable-__cxa_atexit</userinput>: This option
allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
local statics and global objects and is essential for fully standards-compliant
handling of destructors. It also affects the C++ ABI and therefore results in
C++ shared libraries and C++ programs that are interoperable with other Linux
distributions.</para></listitem>
<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option ensures
the correct locale model is selected for the C++ libraries under all
circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
risk of building ABI incompatible C++ libraries due to the wrong locale model of
<emphasis>generic</emphasis> being selected.</para></listitem>
<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option is
needed to ensure that both C and C++ compilers are built.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>There is no need to use the <userinput>bootstrap</userinput> target now,
as the compiler we're using to compile this GCC was built from the exact same
version of the GCC sources we used earlier.</para>
<note><para>It's worth pointing out that running the GCC test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>Test the results:</para>
<screen><userinput>make -k check</userinput></screen>
<para>The <userinput>-k</userinput> flag is used to make the test suite run
through to completion and not stop at the first failure. The GCC test suite is
very comprehensive and is almost guaranteed to generate a few failures. To get
a summary of the test suite results, run this:</para>
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary | more</userinput></screen>
<para>You can compare your results to those posted to the gcc-testresults
mailing list for similar configurations to your own. For an example of how
current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html"/>.</para>
<para>Note that the results contain:</para>
<screen>* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++</screen>
<para>The unexpected pass for g++ is due to the use of
<userinput>--enable-__cxa_atexit</userinput>. Apparently not all platforms
supported by GCC have support for "__cxa_atexit" in their C libraries, so this
test is not always expected to pass.</para>
<para>The 26 unexpected passes for libstdc++ are due to the use of
<userinput>--enable-clocale=gnu</userinput>, which is the correct choice on
Glibc-based systems of versions 2.2.5 and above. The underlying locale support
in the GNU C library is superior to that of the otherwise selected "generic"
model (which may be applicable if for instance you were using Newlibc, Sun-libc
or whatever libc). The libstdc++ test suite is apparently expecting the
"generic" model, hence those tests are not always expected to pass.</para>
<para>Unexpected failures often cannot be avoided. The GCC developers are
usually aware of them but haven't yet gotten around to fixing them. In short,
unless your results are vastly different from those at the above URL, it is safe
to continue on.</para>
<para>And finally install the package:</para>
<screen><userinput>make install</userinput></screen>
<note><para>At this point it is strongly recommended to repeat the sanity check
we performed earlier in the chapter. Refer back to
<xref linkend="ch05-locking-glibc"/> and repeat the check. If the results are
wrong, then most likely you forgot to apply the above mentioned GCC Specs
patch.</para></note>
</sect2>

View File

@ -5,7 +5,170 @@
<screen>Estimated build time: &gcc-time-tools-pass2;
Estimated required disk space: &gcc-compsize-tools-pass2;</screen>
&c5-gcc-pass2-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Re-installation of GCC</title>
<para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
the new Glibc, and test them properly. One thing to note, however, is that these
test suites are highly dependent on properly functioning pseudo terminals (PTYs)
which are provided by your host distribution. These days, PTYs are most commonly
implemented via the <emphasis>devpts</emphasis> file system. You can quickly
check if your host system is set up correctly in this regard by performing a
simple test:</para>
<screen><userinput>expect -c "spawn ls"</userinput></screen>
<para>If you receive the message:</para>
<blockquote><screen>The system has no more ptys. Ask your system administrator to create more.</screen></blockquote>
<para>Your host distribution is not set up for proper PTY operation. In this
case there is no point in running the test suites for GCC and Binutils until you
are able to resolve the issue. You can consult the LFS Wiki at
<ulink url="http://wiki.linuxfromscratch.org/"/> for more information on how to
get PTYs working.</para>
<para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
same working directory. They will all unfold into a single
<filename>gcc-&gcc-version;/</filename> subdirectory.</para>
<para>First correct one problem and make an essential adjustment:</para>
<screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
<para>The first patch disables the GCC "fixincludes" script. We mentioned this
briefly earlier, but a slightly more in-depth explanation of the fixincludes
process is warranted here. Under normal circumstances, the GCC fixincludes
script scans your system for header files that need to be fixed. It might find
that some Glibc header files on your host system need to be fixed, fix them and
put them in the GCC private include directory. Then, later on in
<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
private include directory would be searched before the system include
directory, resulting in GCC finding the fixed headers from the host system,
which would most likely not match the Glibc version actually used for the LFS
system.</para>
<para>The last patch changes GCC's default location of the dynamic linker
(typically <filename>ld-linux.so.2</filename>). It also removes
<filename class="directory">/usr/include</filename> from GCC's include search
path. Patching now rather than adjusting the specs file after installation
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>
<para>Create a separate build directory again:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Before starting to build GCC, remember to unset any environment
variables that override the default optimization flags.</para>
<para>Now prepare GCC to be compiled:</para>
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--with-local-prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-clocale=gnu --enable-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix --enable-__cxa_atexit \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen>
<para>The meaning of the new configure options:</para>
<itemizedlist>
<listitem><para><userinput>--enable-threads=posix</userinput>: This enables
C++ exception handling for multi-threaded code.</para></listitem>
<listitem><para><userinput>--enable-__cxa_atexit</userinput>: This option
allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
local statics and global objects and is essential for fully standards-compliant
handling of destructors. It also affects the C++ ABI and therefore results in
C++ shared libraries and C++ programs that are interoperable with other Linux
distributions.</para></listitem>
<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option ensures
the correct locale model is selected for the C++ libraries under all
circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
risk of building ABI incompatible C++ libraries due to the wrong locale model of
<emphasis>generic</emphasis> being selected.</para></listitem>
<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option is
needed to ensure that both C and C++ compilers are built.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>There is no need to use the <userinput>bootstrap</userinput> target now,
as the compiler we're using to compile this GCC was built from the exact same
version of the GCC sources we used earlier.</para>
<note><para>It's worth pointing out that running the GCC test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>Test the results:</para>
<screen><userinput>make -k check</userinput></screen>
<para>The <userinput>-k</userinput> flag is used to make the test suite run
through to completion and not stop at the first failure. The GCC test suite is
very comprehensive and is almost guaranteed to generate a few failures. To get
a summary of the test suite results, run this:</para>
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary | more</userinput></screen>
<para>You can compare your results to those posted to the gcc-testresults
mailing list for similar configurations to your own. For an example of how
current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html"/>.</para>
<para>Note that the results contain:</para>
<screen>* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++</screen>
<para>The unexpected pass for g++ is due to the use of
<userinput>--enable-__cxa_atexit</userinput>. Apparently not all platforms
supported by GCC have support for "__cxa_atexit" in their C libraries, so this
test is not always expected to pass.</para>
<para>The 26 unexpected passes for libstdc++ are due to the use of
<userinput>--enable-clocale=gnu</userinput>, which is the correct choice on
Glibc-based systems of versions 2.2.5 and above. The underlying locale support
in the GNU C library is superior to that of the otherwise selected "generic"
model (which may be applicable if for instance you were using Newlibc, Sun-libc
or whatever libc). The libstdc++ test suite is apparently expecting the
"generic" model, hence those tests are not always expected to pass.</para>
<para>Unexpected failures often cannot be avoided. The GCC developers are
usually aware of them but haven't yet gotten around to fixing them. In short,
unless your results are vastly different from those at the above URL, it is safe
to continue on.</para>
<para>And finally install the package:</para>
<screen><userinput>make install</userinput></screen>
<note><para>At this point it is strongly recommended to repeat the sanity check
we performed earlier in the chapter. Refer back to
<xref linkend="ch05-locking-glibc"/> and repeat the check. If the results are
wrong, then most likely you forgot to apply the above mentioned GCC Specs
patch.</para></note>
</sect2>
</sect1>

View File

@ -1,29 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gettext</title>
<para>Prepare Gettext to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the programs:</para>
<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
example, if it finds a Java compiler on the host. The Gettext test suite takes
a very long time to run and is not considered critical. Therefore, we don't
recommend running it here. Should you choose to run it, the following command
will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,6 +7,35 @@ Estimated required disk space: &gettext-compsize-tools;</screen>
&aa-gettext-shortdesc;
&aa-gettext-dep;
&c5-gettext-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gettext</title>
<para>Prepare Gettext to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the programs:</para>
<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
example, if it finds a Java compiler on the host. The Gettext test suite takes
a very long time to run and is not considered critical. Therefore, we don't
recommend running it here. Should you choose to run it, the following command
will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,169 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Glibc installation</title>
<para>Before starting to install Glibc, you must <userinput>cd</userinput>
into the <filename>glibc-&glibc-version;</filename> directory and unpack
Glibc-linuxthreads in that directory, not in the directory where you usually
unpack all the sources.</para>
<note><para>We are going to run the test suite for Glibc in this chapter.
However, it's worth pointing out that running the Glibc test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
them when building Glibc.</para>
<para>Basically, compiling Glibc in any other way than the book suggests
is putting the stability of your system at risk.</para>
<para>Though it is a harmless message, the install stage of Glibc will
complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
Fix this annoying little warning with:</para>
<screen><userinput>mkdir /tools/etc
touch /tools/etc/ld.so.conf</userinput></screen>
<para>Also, Glibc has a subtle problem when compiled with GCC &gcc-version;.
Apply the following patch to fix this:</para>
<screen><userinput>patch -Np1 -i ../&glibc-sscanf-patch;</userinput></screen>
<para>The Glibc documentation recommends building Glibc outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../glibc-build
cd ../glibc-build</userinput></screen>
<para>Next, prepare Glibc to be compiled:</para>
<screen><userinput>../glibc-&glibc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-profile --enable-add-ons \
&nbsp;&nbsp;&nbsp;&nbsp;--with-headers=/tools/include \
&nbsp;&nbsp;&nbsp;&nbsp;--with-binutils=/tools/bin \
&nbsp;&nbsp;&nbsp;&nbsp;--without-gd</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--disable-profile</userinput>: This disables the
building of the libraries with profiling information. Omit this option if you
plan to do profiling.</para></listitem>
<listitem><para><userinput>--enable-add-ons</userinput>: This enables any
add-ons that were installed with Glibc, in our case Linuxthreads.</para></listitem>
<listitem><para><userinput>--with-binutils=/tools/bin</userinput> and
<userinput>--with-headers=/tools/include</userinput>: Strictly speaking
these switches are not required. But they ensure nothing can go wrong with
regard to what kernel headers and Binutils programs get used during the
Glibc build.</para></listitem>
<listitem><para><userinput> --without-gd</userinput>: This switch ensures
that we don't build the <userinput>memusagestat</userinput> program, which
strangely enough insists on linking against the host's libraries (libgd,
libpng, libz, and so forth).</para></listitem>
</itemizedlist>
<para>During this stage you might see the following warning:</para>
<blockquote><screen>configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt
*** some features will be disabled.
*** Check the INSTALL file for required versions.</screen></blockquote>
<para>The missing or incompatible <filename>msgfmt</filename> program is
generally harmless, but it's believed it can sometimes cause problems when
running the test suite.</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Run the test suite:</para>
<screen><userinput>make check</userinput></screen>
<para>The Glibc test suite is highly dependent on certain functions of your host
system, in particular the kernel. Additionally, here in this chapter some tests
can be adversely affected by existing tools or environmental issues on the host
system. Of course, these won't be a problem when we run the Glibc test suite
inside the chroot environment of <xref linkend="chapter06"/>. In general, the
Glibc test suite is always expected to pass. However, as mentioned above, some
failures are unavoidable in certain circumstances. Here is a list of the most
common issues we are aware of:</para>
<itemizedlist>
<listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
on systems where the CPU is not a relatively new genuine Intel or authentic AMD.
Certain optimization settings are also known to be a factor here.</para></listitem>
<listitem><para>The <emphasis>gettext</emphasis> test sometimes fails due to
host system issues. The exact reasons are not yet clear.</para></listitem>
<listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
LFS partition is mounted with the <emphasis>noatime</emphasis> option, or due
to other file system quirks.</para></listitem>
<listitem><para>The <emphasis>shm</emphasis> test might fail when the host
system is running the devfs file system but doesn't have the tmpfs file system
mounted at <filename>/dev/shm</filename> due to lack of support for tmpfs in
the kernel.</para></listitem>
<listitem><para>When running on older and slower hardware, some tests might
fail due to test timeouts being exceeded.</para></listitem>
</itemizedlist>
<para>In summary, don't worry too much if you see Glibc test suite failures
here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
ultimately end up using so that is the one we would really like to see pass.
But please keep in mind, even in <xref linkend="chapter06"/> some failures
could still occur -- the <emphasis>math</emphasis>
tests for example. When experiencing a failure, make a note of it, then
continue by reissuing the <userinput>make check</userinput>. The test suite
should pick up where it left off and continue on. You can circumvent this
stop-start sequence by issuing a <userinput>make -k check</userinput>. But if
you do that, be sure to log the output so that you can later peruse the log
file and examine the total number of failures.</para>
<para>Now install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Different countries and cultures have varying conventions for how to
communicate. These conventions range from very simple ones, such as the format
for representing dates and times, to very complex ones, such as the language
spoken. The "internationalization" of GNU programs works by means of
<emphasis>locales</emphasis>. We'll install the Glibc locales now:</para>
<screen><userinput>make localedata/install-locales</userinput></screen>
<para>An alternative to running the previous command is to install only
those locales which you need or want. This can be achieved by using the
<userinput>localedef</userinput> command. Information on this can be
found in the <filename>INSTALL</filename> file in the
<filename>glibc-&glibc-version;</filename> source. However, there are a number
of locales that are essential for the tests of future packages to pass, in
particular, the <emphasis>libstdc++</emphasis> tests from GCC. The following
instructions, instead of the install-locales target above, will install
the minimum set of locales necessary for the tests to run successfully:</para>
<screen><userinput>mkdir -p /tools/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
</sect2>

View File

@ -7,7 +7,175 @@ Estimated required disk space: &glibc-compsize-tools;</screen>
&aa-glibc-shortdesc;
&aa-glibc-dep;
&c5-glibc-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Glibc installation</title>
<para>Before starting to install Glibc, you must <userinput>cd</userinput>
into the <filename>glibc-&glibc-version;</filename> directory and unpack
Glibc-linuxthreads in that directory, not in the directory where you usually
unpack all the sources.</para>
<note><para>We are going to run the test suite for Glibc in this chapter.
However, it's worth pointing out that running the Glibc test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
them when building Glibc.</para>
<para>Basically, compiling Glibc in any other way than the book suggests
is putting the stability of your system at risk.</para>
<para>Though it is a harmless message, the install stage of Glibc will
complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
Fix this annoying little warning with:</para>
<screen><userinput>mkdir /tools/etc
touch /tools/etc/ld.so.conf</userinput></screen>
<para>Also, Glibc has a subtle problem when compiled with GCC &gcc-version;.
Apply the following patch to fix this:</para>
<screen><userinput>patch -Np1 -i ../&glibc-sscanf-patch;</userinput></screen>
<para>The Glibc documentation recommends building Glibc outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../glibc-build
cd ../glibc-build</userinput></screen>
<para>Next, prepare Glibc to be compiled:</para>
<screen><userinput>../glibc-&glibc-version;/configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-profile --enable-add-ons \
&nbsp;&nbsp;&nbsp;&nbsp;--with-headers=/tools/include \
&nbsp;&nbsp;&nbsp;&nbsp;--with-binutils=/tools/bin \
&nbsp;&nbsp;&nbsp;&nbsp;--without-gd</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--disable-profile</userinput>: This disables the
building of the libraries with profiling information. Omit this option if you
plan to do profiling.</para></listitem>
<listitem><para><userinput>--enable-add-ons</userinput>: This enables any
add-ons that were installed with Glibc, in our case Linuxthreads.</para></listitem>
<listitem><para><userinput>--with-binutils=/tools/bin</userinput> and
<userinput>--with-headers=/tools/include</userinput>: Strictly speaking
these switches are not required. But they ensure nothing can go wrong with
regard to what kernel headers and Binutils programs get used during the
Glibc build.</para></listitem>
<listitem><para><userinput> --without-gd</userinput>: This switch ensures
that we don't build the <userinput>memusagestat</userinput> program, which
strangely enough insists on linking against the host's libraries (libgd,
libpng, libz, and so forth).</para></listitem>
</itemizedlist>
<para>During this stage you might see the following warning:</para>
<blockquote><screen>configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt
*** some features will be disabled.
*** Check the INSTALL file for required versions.</screen></blockquote>
<para>The missing or incompatible <filename>msgfmt</filename> program is
generally harmless, but it's believed it can sometimes cause problems when
running the test suite.</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Run the test suite:</para>
<screen><userinput>make check</userinput></screen>
<para>The Glibc test suite is highly dependent on certain functions of your host
system, in particular the kernel. Additionally, here in this chapter some tests
can be adversely affected by existing tools or environmental issues on the host
system. Of course, these won't be a problem when we run the Glibc test suite
inside the chroot environment of <xref linkend="chapter06"/>. In general, the
Glibc test suite is always expected to pass. However, as mentioned above, some
failures are unavoidable in certain circumstances. Here is a list of the most
common issues we are aware of:</para>
<itemizedlist>
<listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
on systems where the CPU is not a relatively new genuine Intel or authentic AMD.
Certain optimization settings are also known to be a factor here.</para></listitem>
<listitem><para>The <emphasis>gettext</emphasis> test sometimes fails due to
host system issues. The exact reasons are not yet clear.</para></listitem>
<listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
LFS partition is mounted with the <emphasis>noatime</emphasis> option, or due
to other file system quirks.</para></listitem>
<listitem><para>The <emphasis>shm</emphasis> test might fail when the host
system is running the devfs file system but doesn't have the tmpfs file system
mounted at <filename>/dev/shm</filename> due to lack of support for tmpfs in
the kernel.</para></listitem>
<listitem><para>When running on older and slower hardware, some tests might
fail due to test timeouts being exceeded.</para></listitem>
</itemizedlist>
<para>In summary, don't worry too much if you see Glibc test suite failures
here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
ultimately end up using so that is the one we would really like to see pass.
But please keep in mind, even in <xref linkend="chapter06"/> some failures
could still occur -- the <emphasis>math</emphasis>
tests for example. When experiencing a failure, make a note of it, then
continue by reissuing the <userinput>make check</userinput>. The test suite
should pick up where it left off and continue on. You can circumvent this
stop-start sequence by issuing a <userinput>make -k check</userinput>. But if
you do that, be sure to log the output so that you can later peruse the log
file and examine the total number of failures.</para>
<para>Now install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Different countries and cultures have varying conventions for how to
communicate. These conventions range from very simple ones, such as the format
for representing dates and times, to very complex ones, such as the language
spoken. The "internationalization" of GNU programs works by means of
<emphasis>locales</emphasis>. We'll install the Glibc locales now:</para>
<screen><userinput>make localedata/install-locales</userinput></screen>
<para>An alternative to running the previous command is to install only
those locales which you need or want. This can be achieved by using the
<userinput>localedef</userinput> command. Information on this can be
found in the <filename>INSTALL</filename> file in the
<filename>glibc-&glibc-version;</filename> source. However, there are a number
of locales that are essential for the tests of future packages to pass, in
particular, the <emphasis>libstdc++</emphasis> tests from GCC. The following
instructions, instead of the install-locales target above, will install
the minimum set of locales necessary for the tests to run successfully:</para>
<screen><userinput>mkdir -p /tools/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
</sect2>
</sect1>

View File

@ -1,38 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Grep</title>
<para>Prepare Grep to be compiled:</para>
<screen><userinput>./configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-perl-regexp --with-included-regex</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--disable-perl-regexp</userinput>: This makes sure
that <userinput>grep</userinput> does not get linked against a PCRE library
that may be present on the host, but would not be available once we enter the
chroot environment.</para></listitem>
<listitem><para><userinput>--with-included-regex</userinput>: This ensures that
Grep uses its internal regular expression code. Without it, it will use
the code from Glibc, which is known to be slightly buggy.</para></listitem>
</itemizedlist>
<para>Compile the programs:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,44 @@ Estimated required disk space: &grep-compsize-tools;</screen>
&aa-grep-shortdesc;
&aa-grep-dep;
&c5-grep-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Grep</title>
<para>Prepare Grep to be compiled:</para>
<screen><userinput>./configure --prefix=/tools \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-perl-regexp --with-included-regex</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--disable-perl-regexp</userinput>: This makes sure
that <userinput>grep</userinput> does not get linked against a PCRE library
that may be present on the host, but would not be available once we enter the
chroot environment.</para></listitem>
<listitem><para><userinput>--with-included-regex</userinput>: This ensures that
Grep uses its internal regular expression code. Without it, it will use
the code from Glibc, which is known to be slightly buggy.</para></listitem>
</itemizedlist>
<para>Compile the programs:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,19 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gzip</title>
<para>Prepare Gzip to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,25 @@ Estimated required disk space: &gzip-compsize-tools;</screen>
&aa-gzip-shortdesc;
&aa-gzip-dep;
&c5-gzip-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gzip</title>
<para>Prepare Gzip to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,46 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of the kernel headers</title>
<para>As some packages need to refer to the kernel header files, we're going
to unpack the kernel archive now, set it up, and copy the required files to a
place where <userinput>gcc</userinput> can later find them.</para>
<para>Prepare for the header installation with:</para>
<screen><userinput>make mrproper</userinput></screen>
<para>This ensures that the kernel tree is absolutely clean. The kernel team
recommends that this command be issued prior to <emphasis>each</emphasis> kernel
compilation. You shouldn't rely on the source tree being clean after
untarring.</para>
<para>Create the <filename>include/linux/version.h</filename> file:</para>
<screen><userinput>make include/linux/version.h</userinput></screen>
<para>Create the platform-specific <filename>include/asm</filename>
symlink:</para>
<screen><userinput>make symlinks</userinput></screen>
<para>Install the platform-specific header files:</para>
<screen><userinput>mkdir /tools/include/asm
cp include/asm/* /tools/include/asm
cp -R include/asm-generic /tools/include</userinput></screen>
<para>Install the cross-platform kernel header files:</para>
<screen><userinput>cp -R include/linux /tools/include</userinput></screen>
<para>There are a few kernel header files which make use of the
<filename>autoconf.h</filename> header file. Since we do not yet configure the
kernel, we need to create this file ourselves in order to avoid compilation
failures. Create an empty <filename>autoconf.h</filename> file:</para>
<screen><userinput>touch /tools/include/linux/autoconf.h</userinput></screen>
</sect2>

View File

@ -7,7 +7,52 @@ Estimated required disk space: &kernel-compsize-headers;</screen>
&aa-kernel-shortdesc;
&aa-kernel-dep;
&c5-kernelheaders-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of the kernel headers</title>
<para>As some packages need to refer to the kernel header files, we're going
to unpack the kernel archive now, set it up, and copy the required files to a
place where <userinput>gcc</userinput> can later find them.</para>
<para>Prepare for the header installation with:</para>
<screen><userinput>make mrproper</userinput></screen>
<para>This ensures that the kernel tree is absolutely clean. The kernel team
recommends that this command be issued prior to <emphasis>each</emphasis> kernel
compilation. You shouldn't rely on the source tree being clean after
untarring.</para>
<para>Create the <filename>include/linux/version.h</filename> file:</para>
<screen><userinput>make include/linux/version.h</userinput></screen>
<para>Create the platform-specific <filename>include/asm</filename>
symlink:</para>
<screen><userinput>make symlinks</userinput></screen>
<para>Install the platform-specific header files:</para>
<screen><userinput>mkdir /tools/include/asm
cp include/asm/* /tools/include/asm
cp -R include/asm-generic /tools/include</userinput></screen>
<para>Install the cross-platform kernel header files:</para>
<screen><userinput>cp -R include/linux /tools/include</userinput></screen>
<para>There are a few kernel header files which make use of the
<filename>autoconf.h</filename> header file. Since we do not yet configure the
kernel, we need to create this file ourselves in order to avoid compilation
failures. Create an empty <filename>autoconf.h</filename> file:</para>
<screen><userinput>touch /tools/include/linux/autoconf.h</userinput></screen>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Make</title>
<para>Prepare Make to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the program:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &make-compsize-tools;</screen>
&aa-make-shortdesc;
&aa-make-dep;
&c5-make-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Make</title>
<para>Prepare Make to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the program:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,43 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Ncurses</title>
<para>Fix two minor things:</para>
<screen><userinput>patch -Np1 -i ../&ncurses-etip-patch;
patch -Np1 -i ../&ncurses-vsscanf-patch;</userinput></screen>
<para>The first patch corrects the <filename>etip.h</filename> header file, and
the second patch prevents some compiler warnings being issued on the use of
deprecated headers.</para>
<para>Now prepare Ncurses to be compiled:</para>
<screen><userinput>./configure --prefix=/tools --with-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--without-debug --without-ada --enable-overwrite</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--without-ada</userinput>: This tells Ncurses not
to build its Ada bindings, even if an Ada compiler is installed on the host.
This must be done because once we enter the chroot environment, Ada will no
longer be available.</para></listitem>
<listitem><para><userinput>--enable-overwrite</userinput>: This tells Ncurses
to install its header files into <filename class="directory">/tools/include</filename>
instead of <filename class="directory">/tools/include/ncurses</filename> to
ensure that other packages can find the Ncurses headers successfully.</para>
</listitem></itemizedlist>
<para>Compile the programs and libraries:</para>
<screen><userinput>make </userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,49 @@ Estimated required disk space: &ncurses-compsize-tools;</screen>
&aa-ncurses-shortdesc;
&aa-ncurses-dep;
&c5-ncurses-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Ncurses</title>
<para>Fix two minor things:</para>
<screen><userinput>patch -Np1 -i ../&ncurses-etip-patch;
patch -Np1 -i ../&ncurses-vsscanf-patch;</userinput></screen>
<para>The first patch corrects the <filename>etip.h</filename> header file, and
the second patch prevents some compiler warnings being issued on the use of
deprecated headers.</para>
<para>Now prepare Ncurses to be compiled:</para>
<screen><userinput>./configure --prefix=/tools --with-shared \
&nbsp;&nbsp;&nbsp;&nbsp;--without-debug --without-ada --enable-overwrite</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--without-ada</userinput>: This tells Ncurses not
to build its Ada bindings, even if an Ada compiler is installed on the host.
This must be done because once we enter the chroot environment, Ada will no
longer be available.</para></listitem>
<listitem><para><userinput>--enable-overwrite</userinput>: This tells Ncurses
to install its header files into <filename class="directory">/tools/include</filename>
instead of <filename class="directory">/tools/include/ncurses</filename> to
ensure that other packages can find the Ncurses headers successfully.</para>
</listitem></itemizedlist>
<para>Compile the programs and libraries:</para>
<screen><userinput>make </userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,22 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Patch</title>
<para>Prepare Patch to be compiled:</para>
<screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools</userinput></screen>
<para>The preprocessor flag <userinput>-D_GNU_SOURCE</userinput> is only needed
on the PowerPC platform. On other architectures you can leave it out.</para>
<para>Compile the program:</para>
<screen><userinput>make </userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,28 @@ Estimated required disk space: &patch-compsize-tools;</screen>
&aa-patch-shortdesc;
&aa-patch-dep;
&c5-patch-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Patch</title>
<para>Prepare Patch to be compiled:</para>
<screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools</userinput></screen>
<para>The preprocessor flag <userinput>-D_GNU_SOURCE</userinput> is only needed
on the PowerPC platform. On other architectures you can leave it out.</para>
<para>Compile the program:</para>
<screen><userinput>make </userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,29 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Perl</title>
<para>First adapt some hard-wired paths to the C library:</para>
<screen><userinput>patch -Np1 -i ../&perl-libc-patch;</userinput></screen>
<para>And make sure some static extensions get built:</para>
<screen><userinput>chmod u+w hints/linux.sh
echo 'static_ext="IO re Fcntl"' >> hints/linux.sh</userinput></screen>
<para>Now prepare Perl for compilation:</para>
<screen><userinput>./configure.gnu --prefix=/tools</userinput></screen>
<para>Compile only the required tools:</para>
<screen><userinput>make perl utilities</userinput></screen>
<para>Then copy these tools and their libraries:</para>
<screen><userinput>cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/&perl-version;
cp -R lib/* /tools/lib/perl5/&perl-version;</userinput></screen>
</sect2>

View File

@ -7,7 +7,35 @@ Estimated required disk space: &perl-compsize-tools;</screen>
&aa-perl-shortdesc;
&aa-perl-dep;
&c5-perl-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Perl</title>
<para>First adapt some hard-wired paths to the C library:</para>
<screen><userinput>patch -Np1 -i ../&perl-libc-patch;</userinput></screen>
<para>And make sure some static extensions get built:</para>
<screen><userinput>chmod u+w hints/linux.sh
echo 'static_ext="IO re Fcntl"' >> hints/linux.sh</userinput></screen>
<para>Now prepare Perl for compilation:</para>
<screen><userinput>./configure.gnu --prefix=/tools</userinput></screen>
<para>Compile only the required tools:</para>
<screen><userinput>make perl utilities</userinput></screen>
<para>Then copy these tools and their libraries:</para>
<screen><userinput>cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/&perl-version;
cp -R lib/* /tools/lib/perl5/&perl-version;</userinput></screen>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Sed</title>
<para>Prepare Sed to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the program:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &sed-compsize-tools;</screen>
&aa-sed-shortdesc;
&aa-sed-dep;
&c5-sed-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Sed</title>
<para>Prepare Sed to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the program:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install it and its documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Tar</title>
<para>Prepare Tar to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the programs:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &tar-compsize-tools;</screen>
&aa-tar-shortdesc;
&aa-tar-dep;
&c5-tar-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Tar</title>
<para>Prepare Tar to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the programs:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,57 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Tcl</title>
<para>This package and the next two are only installed to be able to run the
test suites for GCC and Binutils. Installing three packages just for testing
purposes may seem like overkill, but it is very reassuring, if not essential,
to know that our most important tools are working properly.</para>
<para>Prepare Tcl to be compiled:</para>
<screen><userinput>cd unix
./configure --prefix=/tools</userinput></screen>
<para>Build the package:</para>
<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 Tcl test suite in this
chapter 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 suite, the
following command will do so:</para>
<screen><userinput>TZ=UTC make test</userinput></screen>
<para>The meaning of the make option:</para>
<itemizedlist>
<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>
</itemizedlist>
<para>Sometimes, package test suites will give false failures. You can
consult the LFS Wiki at <ulink url="http://wiki.linuxfromscratch.org/"/>
to verify that these failures are normal. This applies to all tests
throughout the book.</para>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<important><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>
<para>Make a necessary symbolic link:</para>
<screen><userinput>ln -s tclsh8.4 /tools/bin/tclsh</userinput></screen>
</sect2>

View File

@ -7,7 +7,63 @@ Estimated required disk space: &tcl-compsize-tools;</screen>
&aa-tcl-shortdesc;
&aa-tcl-dep;
&c5-tcl-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Tcl</title>
<para>This package and the next two are only installed to be able to run the
test suites for GCC and Binutils. Installing three packages just for testing
purposes may seem like overkill, but it is very reassuring, if not essential,
to know that our most important tools are working properly.</para>
<para>Prepare Tcl to be compiled:</para>
<screen><userinput>cd unix
./configure --prefix=/tools</userinput></screen>
<para>Build the package:</para>
<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 Tcl test suite in this
chapter 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 suite, the
following command will do so:</para>
<screen><userinput>TZ=UTC make test</userinput></screen>
<para>The meaning of the make option:</para>
<itemizedlist>
<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>
</itemizedlist>
<para>Sometimes, package test suites will give false failures. You can
consult the LFS Wiki at <ulink url="http://wiki.linuxfromscratch.org/"/>
to verify that these failures are normal. This applies to all tests
throughout the book.</para>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<important><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>
<para>Make a necessary symbolic link:</para>
<screen><userinput>ln -s tclsh8.4 /tools/bin/tclsh</userinput></screen>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Texinfo</title>
<para>Prepare Texinfo to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the programs:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &texinfo-compsize-tools;</screen>
&aa-texinfo-shortdesc;
&aa-texinfo-dep;
&c5-texinfo-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Texinfo</title>
<para>Prepare Texinfo to be compiled:</para>
<screen><userinput>./configure --prefix=/tools</userinput></screen>
<para>Compile the programs:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Then install them and their documentation:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,31 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<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>
<screen><userinput>cp configure configure.backup
sed "s@/usr/include@/tools/include@g" configure.backup &gt; configure</userinput> </screen>
<para>Prepare Util-linux for compilation:</para>
<screen><userinput>./configure</userinput></screen>
<para>Compile some support routines:</para>
<screen><userinput>make -C lib</userinput></screen>
<para>And, since you'll need only a couple of the utilities contained in this
package, build just those:</para>
<screen><userinput>make -C mount mount umount
make -C text-utils more</userinput></screen>
<para>Now copy these programs to the temporary tools directory:</para>
<screen><userinput>cp mount/{,u}mount text-utils/more /tools/bin</userinput></screen>
</sect2>

View File

@ -7,6 +7,37 @@ Estimated required disk space: &util-linux-compsize-tools;</screen>
&aa-utillinux-shortdesc;
&aa-utillinux-dep;
&c5-utillinux-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<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>
<screen><userinput>cp configure configure.backup
sed "s@/usr/include@/tools/include@g" configure.backup &gt; configure</userinput> </screen>
<para>Prepare Util-linux for compilation:</para>
<screen><userinput>./configure</userinput></screen>
<para>Compile some support routines:</para>
<screen><userinput>make -C lib</userinput></screen>
<para>And, since you'll need only a couple of the utilities contained in this
package, build just those:</para>
<screen><userinput>make -C mount mount umount
make -C text-utils more</userinput></screen>
<para>Now copy these programs to the temporary tools directory:</para>
<screen><userinput>cp mount/{,u}mount text-utils/more /tools/bin</userinput></screen>
</sect2>
</sect1>

View File

@ -1,24 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Autoconf</title>
<para>Prepare Autoconf for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,6 +7,30 @@ Estimated required disk space: &autoconf-compsize;</screen>
&aa-autoconf-shortdesc;
&aa-autoconf-dep;
&c6-autoconf-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Autoconf</title>
<para>Prepare Autoconf for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,28 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Automake</title>
<para>Prepare Automake for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And create a necessary symbolic link:</para>
<screen><userinput>ln -s automake-1.7 /usr/share/automake</userinput></screen>
</sect2>

View File

@ -7,6 +7,35 @@ Estimated required disk space: &automake-compsize;</screen>
&aa-automake-shortdesc;
&aa-automake-dep;
&c6-automake-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Automake</title>
<para>Prepare Automake for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And create a necessary symbolic link:</para>
<screen><userinput>ln -s automake-1.7 /usr/share/automake</userinput></screen>
</sect2>
</sect1>

View File

@ -1,34 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bash</title>
<para>Bash has a number of bugs in it that cause it to not behave the
way it is expected at times. Fix this behaviour with the following
patch:</para>
<screen><userinput>patch -Np1 -i ../&bash-patch;</userinput></screen>
<para>Prepare Bash for compilation:</para>
<screen><userinput>./configure --prefix=/usr --bindir=/bin</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make tests</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And reload the newly compiled <userinput>bash</userinput> program:</para>
<screen><userinput>exec /bin/bash --login +h</userinput></screen>
</sect2>

View File

@ -7,6 +7,41 @@ Estimated required disk space: &bash-compsize;</screen>
&aa-bash-shortdesc;
&aa-bash-dep;
&c6-bash-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bash</title>
<para>Bash has a number of bugs in it that cause it to not behave the
way it is expected at times. Fix this behaviour with the following
patch:</para>
<screen><userinput>patch -Np1 -i ../&bash-patch;</userinput></screen>
<para>Prepare Bash for compilation:</para>
<screen><userinput>./configure --prefix=/usr --bindir=/bin</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make tests</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And reload the newly compiled <userinput>bash</userinput> program:</para>
<screen><userinput>exec /bin/bash --login +h</userinput></screen>
</sect2>
</sect1>

View File

@ -1,72 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2><title>Installation of Binutils</title>
<para>Now is an appropriate time to verify that your pseudo terminals (PTYs) are
working properly inside the chroot environment. We will again quickly check that
everything is set up correctly by performing a simple test:</para>
<screen><userinput>expect -c "spawn ls"</userinput></screen>
<para>If you receive the message:</para>
<blockquote><screen>The system has no more ptys. Ask your system administrator to create more.</screen></blockquote>
<para>Your chroot environment is not set up for proper PTY operation. In this
case there is no point in running the test suites for Binutils and GCC until you
are able to resolve the issue. Please refer back to <xref linkend="ch06-proc"/>
and <xref linkend="ch06-makedev"/> and perform the recommended steps to fix the
problem.</para>
<note><para>The test suite for Binutils in this section is considered
<emphasis>critical</emphasis>. Our advice is to not skip it under any
circumstances.</para> </note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building Binutils.</para>
<para>The Binutils documentation recommends building Binutils outside of the
source directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../binutils-build
cd ../binutils-build</userinput></screen>
<para>Now prepare Binutils for compilation:</para>
<screen><userinput>../binutils-&binutils-version;/configure \
&nbsp;&nbsp;&nbsp;&nbsp;--prefix=/usr --enable-shared</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make tooldir=/usr</userinput></screen>
<para>Normally, the <emphasis>tooldir</emphasis> (the directory where the
executables end up) is set to $(exec_prefix)/$(target_alias), which expands
into, for example, <filename>/usr/i686-pc-linux-gnu</filename>. Since we only
build for our own system, we don't need this target specific directory in
<filename>/usr</filename>. That setup would be used if the system was used to
cross-compile (for example compiling a package on an Intel machine that
generates code that can be executed on PowerPC machines).</para>
<para>Test the results:</para>
<screen><userinput>make check</userinput></screen>
<para>The test suite notes from <xref linkend="ch05-binutils-pass2"/> are still
very much appropriate here. Be sure to refer back there should you have any
doubts.</para>
<para>Install the package:</para>
<screen><userinput>make tooldir=/usr install</userinput></screen>
<para>Install the <emphasis>libiberty</emphasis> header file that is needed by
some packages:</para>
<screen><userinput>cp ../binutils-&binutils-version;/include/libiberty.h /usr/include</userinput></screen>
</sect2>

View File

@ -7,6 +7,78 @@ Estimated required disk space: &binutils-compsize;</screen>
&aa-binutils-shortdesc;
&aa-binutils-dep;
&c6-binutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2><title>Installation of Binutils</title>
<para>Now is an appropriate time to verify that your pseudo terminals (PTYs) are
working properly inside the chroot environment. We will again quickly check that
everything is set up correctly by performing a simple test:</para>
<screen><userinput>expect -c "spawn ls"</userinput></screen>
<para>If you receive the message:</para>
<blockquote><screen>The system has no more ptys. Ask your system administrator to create more.</screen></blockquote>
<para>Your chroot environment is not set up for proper PTY operation. In this
case there is no point in running the test suites for Binutils and GCC until you
are able to resolve the issue. Please refer back to <xref linkend="ch06-proc"/>
and <xref linkend="ch06-makedev"/> and perform the recommended steps to fix the
problem.</para>
<note><para>The test suite for Binutils in this section is considered
<emphasis>critical</emphasis>. Our advice is to not skip it under any
circumstances.</para> </note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building Binutils.</para>
<para>The Binutils documentation recommends building Binutils outside of the
source directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../binutils-build
cd ../binutils-build</userinput></screen>
<para>Now prepare Binutils for compilation:</para>
<screen><userinput>../binutils-&binutils-version;/configure \
&nbsp;&nbsp;&nbsp;&nbsp;--prefix=/usr --enable-shared</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make tooldir=/usr</userinput></screen>
<para>Normally, the <emphasis>tooldir</emphasis> (the directory where the
executables end up) is set to $(exec_prefix)/$(target_alias), which expands
into, for example, <filename>/usr/i686-pc-linux-gnu</filename>. Since we only
build for our own system, we don't need this target specific directory in
<filename>/usr</filename>. That setup would be used if the system was used to
cross-compile (for example compiling a package on an Intel machine that
generates code that can be executed on PowerPC machines).</para>
<para>Test the results:</para>
<screen><userinput>make check</userinput></screen>
<para>The test suite notes from <xref linkend="ch05-binutils-pass2"/> are still
very much appropriate here. Be sure to refer back there should you have any
doubts.</para>
<para>Install the package:</para>
<screen><userinput>make tooldir=/usr install</userinput></screen>
<para>Install the <emphasis>libiberty</emphasis> header file that is needed by
some packages:</para>
<screen><userinput>cp ../binutils-&binutils-version;/include/libiberty.h /usr/include</userinput></screen>
</sect2>
</sect1>

View File

@ -1,30 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bison</title>
<para>First we use a patch to bison, backported from CVS, which fixes a minor
compilation problem with some packages:</para>
<screen><userinput>patch -Np1 -i ../&bison-patch;</userinput></screen>
<para>Prepare Bison for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so (and takes a long time):</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,36 @@ Estimated required disk space: &bison-compsize;</screen>
&aa-bison-shortdesc;
&aa-bison-dep;
&c6-bison-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bison</title>
<para>First we use a patch to bison, backported from CVS, which fixes a minor
compilation problem with some packages:</para>
<screen><userinput>patch -Np1 -i ../&bison-patch;</userinput></screen>
<para>Prepare Bison for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so (and takes a long time):</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of LFS-Bootscripts</title>
<para>We will be using SysV style init scripts. We have chosen this style
because it is widely used and we feel comfortable with it. If you would prefer
to try something else, Marc Heerdink has written a hint about BSD style init
scripts, to be found at <ulink url="&hints-root;bsd-init.txt"/>. And if you'd
like something more radical, search the LFS mailing lists for depinit.</para>
<para>If you decide to use BSD style, or some other style scripts, you can
skip the next chapter when you arrive at it and move on to
<xref linkend="chapter08"/>.</para>
<para>Install the boot scripts:</para>
<screen><userinput>cp -a rc.d sysconfig /etc</userinput></screen>
<para>Give <emphasis>root</emphasis> ownership of the scripts:</para>
<screen><userinput>chown -R root:root /etc/rc.d /etc/sysconfig</userinput></screen>
</sect2>

View File

@ -7,7 +7,31 @@ Estimated required disk space: &bootscripts-compsize;</screen>
&aa-bootscripts-shortdesc;
&aa-bootscripts-dep;
&c6-bootscripts-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of LFS-Bootscripts</title>
<para>We will be using SysV style init scripts. We have chosen this style
because it is widely used and we feel comfortable with it. If you would prefer
to try something else, Marc Heerdink has written a hint about BSD style init
scripts, to be found at <ulink url="&hints-root;bsd-init.txt"/>. And if you'd
like something more radical, search the LFS mailing lists for depinit.</para>
<para>If you decide to use BSD style, or some other style scripts, you can
skip the next chapter when you arrive at it and move on to
<xref linkend="chapter08"/>.</para>
<para>Install the boot scripts:</para>
<screen><userinput>cp -a rc.d sysconfig /etc</userinput></screen>
<para>Give <emphasis>root</emphasis> ownership of the scripts:</para>
<screen><userinput>chown -R root:root /etc/rc.d /etc/sysconfig</userinput></screen>
</sect2>
</sect1>

View File

@ -1,37 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bzip2</title>
<para>Prepare Bzip2 for compilation with:</para>
<screen><userinput>make -f Makefile-libbz2_so
make clean</userinput></screen>
<para>The <emphasis>-f</emphasis> flag will cause Bzip2 to be built
using a different <filename>Makefile</filename> file, in this case the
<filename>Makefile-libbz2_so</filename> file, which creates a dynamic
<filename>libbz2.so</filename> library and links the bzip2 utilities
against it.</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Install it:</para>
<screen><userinput>make install</userinput></screen>
<para>And install the shared <userinput>bzip2</userinput> binary into the
<filename class="directory">/bin</filename> directory, then make some
necessary symbolic links, and clean up.</para>
<screen><userinput>cp bzip2-shared /bin/bzip2
cp -a libbz2.so* /lib
ln -s ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so
rm /usr/bin/{bunzip2,bzcat,bzip2}
mv /usr/bin/{bzip2recover,bzless,bzmore} /bin
ln -s bzip2 /bin/bunzip2
ln -s bzip2 /bin/bzcat</userinput></screen>
</sect2>

View File

@ -7,6 +7,44 @@ Estimated required disk space: &bzip2-compsize;</screen>
&aa-bzip2-shortdesc;
&aa-bzip2-dep;
&c6-bzip2-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Bzip2</title>
<para>Prepare Bzip2 for compilation with:</para>
<screen><userinput>make -f Makefile-libbz2_so
make clean</userinput></screen>
<para>The <emphasis>-f</emphasis> flag will cause Bzip2 to be built
using a different <filename>Makefile</filename> file, in this case the
<filename>Makefile-libbz2_so</filename> file, which creates a dynamic
<filename>libbz2.so</filename> library and links the bzip2 utilities
against it.</para>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Install it:</para>
<screen><userinput>make install</userinput></screen>
<para>And install the shared <userinput>bzip2</userinput> binary into the
<filename class="directory">/bin</filename> directory, then make some
necessary symbolic links, and clean up.</para>
<screen><userinput>cp bzip2-shared /bin/bzip2
cp -a libbz2.so* /lib
ln -s ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so
rm /usr/bin/{bunzip2,bzcat,bzip2}
mv /usr/bin/{bzip2recover,bzless,bzmore} /bin
ln -s bzip2 /bin/bunzip2
ln -s bzip2 /bin/bzcat</userinput></screen>
</sect2>
</sect1>

View File

@ -1,78 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Coreutils</title>
<para>Normally the functionality of <userinput>uname</userinput> is somewhat
broken, in that the <userinput>-p</userinput> switch always returns "unknown".
The following patch fixes this behaviour for Intel architectures:</para>
<screen><userinput>patch -Np1 -i ../&coreutils-uname-patch;</userinput></screen>
<para>We do not want Coreutils to install its version of the
<userinput>hostname</userinput> program, because it is inferior to the version
provided by Net-tools. Prevent its installation by applying a patch:</para>
<screen><userinput>patch -Np1 -i ../&coreutils-hostname-patch;</userinput></screen>
<para>Now prepare Coreutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>The <userinput>su</userinput> program from Coreutils wasn't installed in
Chapter 5 because it needed <emphasis>root</emphasis> privilege to do so. We're
going to need it in a few moments for the test suite. Therefore we work around
the problem by installing it now:</para>
<screen><userinput>make install-root</userinput></screen>
<para>This package has a test suite available which can perform a number of
checks to ensure it built correctly. However, this particular test suite
makes some assumptions with regards to the presence of non-root users and
groups that don't apply this early into the LFS build. We therefore create
a dummy system user and two dummy groups to allow the tests to run
properly. Should you choose not to run the test suite, skip down to
"Install the package". The following commands will prepare us for the test
suite. Create two dummy groups and a dummy user name:</para>
<screen><userinput>echo "dummy1:x:1000" >> /etc/group
echo "dummy2:x:1001:dummy" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd</userinput></screen>
<para>Some tests are meant to run as <emphasis>root</emphasis>:</para>
<screen><userinput>make check-root</userinput></screen>
<para>The remainder of the tests are run as the <emphasis>dummy</emphasis>
user:</para>
<screen><userinput>su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"</userinput></screen>
<para>Remove the dummy groups and user name:</para>
<screen><userinput>sed -i.bak '/dummy/d' /etc/passwd /etc/group</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And move some programs to their proper locations:</para>
<screen><userinput>mv /usr/bin/{basename,cat,chgrp,chmod,chown,cp,dd,df} /bin
mv /usr/bin/{dir,dircolors,du,date,echo,false,head} /bin
mv /usr/bin/{install,ln,ls,mkdir,mkfifo,mknod,mv,pwd} /bin
mv /usr/bin/{rm,rmdir,shred,sync,sleep,stty,su,test} /bin
mv /usr/bin/{touch,true,uname,vdir} /bin
mv /usr/bin/chroot /usr/sbin</userinput></screen>
<para>Finally, create a few necessary symlinks:</para>
<screen><userinput>ln -s test /bin/[
ln -s ../../bin/install /usr/bin</userinput></screen>
</sect2>

View File

@ -7,7 +7,84 @@ Estimated required disk space: &coreutils-compsize;</screen>
&aa-coreutils-shortdesc;
&aa-coreutils-dep;
&c6-coreutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Coreutils</title>
<para>Normally the functionality of <userinput>uname</userinput> is somewhat
broken, in that the <userinput>-p</userinput> switch always returns "unknown".
The following patch fixes this behaviour for Intel architectures:</para>
<screen><userinput>patch -Np1 -i ../&coreutils-uname-patch;</userinput></screen>
<para>We do not want Coreutils to install its version of the
<userinput>hostname</userinput> program, because it is inferior to the version
provided by Net-tools. Prevent its installation by applying a patch:</para>
<screen><userinput>patch -Np1 -i ../&coreutils-hostname-patch;</userinput></screen>
<para>Now prepare Coreutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>The <userinput>su</userinput> program from Coreutils wasn't installed in
Chapter 5 because it needed <emphasis>root</emphasis> privilege to do so. We're
going to need it in a few moments for the test suite. Therefore we work around
the problem by installing it now:</para>
<screen><userinput>make install-root</userinput></screen>
<para>This package has a test suite available which can perform a number of
checks to ensure it built correctly. However, this particular test suite
makes some assumptions with regards to the presence of non-root users and
groups that don't apply this early into the LFS build. We therefore create
a dummy system user and two dummy groups to allow the tests to run
properly. Should you choose not to run the test suite, skip down to
"Install the package". The following commands will prepare us for the test
suite. Create two dummy groups and a dummy user name:</para>
<screen><userinput>echo "dummy1:x:1000" >> /etc/group
echo "dummy2:x:1001:dummy" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd</userinput></screen>
<para>Some tests are meant to run as <emphasis>root</emphasis>:</para>
<screen><userinput>make check-root</userinput></screen>
<para>The remainder of the tests are run as the <emphasis>dummy</emphasis>
user:</para>
<screen><userinput>su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"</userinput></screen>
<para>Remove the dummy groups and user name:</para>
<screen><userinput>sed -i.bak '/dummy/d' /etc/passwd /etc/group</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And move some programs to their proper locations:</para>
<screen><userinput>mv /usr/bin/{basename,cat,chgrp,chmod,chown,cp,dd,df} /bin
mv /usr/bin/{dir,dircolors,du,date,echo,false,head} /bin
mv /usr/bin/{install,ln,ls,mkdir,mkfifo,mknod,mv,pwd} /bin
mv /usr/bin/{rm,rmdir,shred,sync,sleep,stty,su,test} /bin
mv /usr/bin/{touch,true,uname,vdir} /bin
mv /usr/bin/chroot /usr/sbin</userinput></screen>
<para>Finally, create a few necessary symlinks:</para>
<screen><userinput>ln -s test /bin/[
ln -s ../../bin/install /usr/bin</userinput></screen>
</sect2>
</sect1>

View File

@ -1,19 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Diffutils</title>
<para>Prepare Diffutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,6 +7,25 @@ Estimated required disk space: &diffutils-compsize;</screen>
&aa-diffutils-shortdesc;
&aa-diffutils-dep;
&c6-diffutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Diffutils</title>
<para>Prepare Diffutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,55 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of E2fsprogs</title>
<para>It is recommended to build E2fsprogs outside of the
source tree:</para>
<screen><userinput>mkdir ../e2fsprogs-build
cd ../e2fsprogs-build</userinput></screen>
<para>Prepare E2fsprogs for compilation:</para>
<screen><userinput>../e2fsprogs-&e2fsprogs-version;/configure --prefix=/usr --with-root-prefix="" \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-elf-shlibs</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--with-root-prefix=""</userinput>: Certain
programs (such as the e2fsck program) are considered essential programs.
When, for example, <filename class="directory">/usr</filename> isn't
mounted, these essential program have to be available. They belong in
directories like <filename class="directory">/lib</filename> and
<filename class="directory">/sbin</filename>. If this option isn't passed
to E2fsprogs's configure, the programs are placed in the
<filename class="directory">/usr</filename> directory, which is not what we
want.</para></listitem>
<listitem><para><userinput>--enable-elf-shlibs</userinput>: This creates
the shared libraries which some programs in this package make use
of.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Install most of the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And install also the shared libraries:</para>
<screen><userinput>make install-libs</userinput></screen>
</sect2>

View File

@ -7,6 +7,61 @@ Estimated required disk space: &e2fsprogs-compsize;</screen>
&aa-e2fsprogs-shortdesc;
&aa-e2fsprogs-dep;
&c6-e2fsprogs-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of E2fsprogs</title>
<para>It is recommended to build E2fsprogs outside of the
source tree:</para>
<screen><userinput>mkdir ../e2fsprogs-build
cd ../e2fsprogs-build</userinput></screen>
<para>Prepare E2fsprogs for compilation:</para>
<screen><userinput>../e2fsprogs-&e2fsprogs-version;/configure --prefix=/usr --with-root-prefix="" \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-elf-shlibs</userinput></screen>
<para>The meaning of the configure options:</para>
<itemizedlist>
<listitem><para><userinput>--with-root-prefix=""</userinput>: Certain
programs (such as the e2fsck program) are considered essential programs.
When, for example, <filename class="directory">/usr</filename> isn't
mounted, these essential program have to be available. They belong in
directories like <filename class="directory">/lib</filename> and
<filename class="directory">/sbin</filename>. If this option isn't passed
to E2fsprogs's configure, the programs are placed in the
<filename class="directory">/usr</filename> directory, which is not what we
want.</para></listitem>
<listitem><para><userinput>--enable-elf-shlibs</userinput>: This creates
the shared libraries which some programs in this package make use
of.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Install most of the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And install also the shared libraries:</para>
<screen><userinput>make install-libs</userinput></screen>
</sect2>
</sect1>

View File

@ -1,47 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Ed</title>
<note><para>Ed isn't something which many people use. It's installed here
because it can be used by the patch program if you encounter an ed-based patch
file. This happens rarely because diff-based patches are preferred these
days.</para></note>
<para>Ed normally uses the mktemp function to create temporary files in
<filename class="directory">/tmp</filename>, but this function contains a
vulnerability (see the section on Temporary Files in <ulink
url="http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html"/>). The
following patch makes Ed use mkstemp instead, which is the recommended way to
create temporary files.</para>
<para>Apply the patch:</para>
<screen><userinput>patch -Np1 -i ../&ed-patch;</userinput></screen>
<para>Now prepare Ed for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And move the programs to the <filename>/bin</filename> directory, so
they can be used in the event that the <filename>/usr</filename> partition is
unavailable.</para>
<screen><userinput>mv /usr/bin/{ed,red} /bin</userinput></screen>
</sect2>

View File

@ -7,8 +7,53 @@ Estimated required disk space: &ed-compsize;</screen>
&aa-ed-shortdesc;
&aa-ed-dep;
&c6-ed-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Ed</title>
<note><para>Ed isn't something which many people use. It's installed here
because it can be used by the patch program if you encounter an ed-based patch
file. This happens rarely because diff-based patches are preferred these
days.</para></note>
<para>Ed normally uses the mktemp function to create temporary files in
<filename class="directory">/tmp</filename>, but this function contains a
vulnerability (see the section on Temporary Files in <ulink
url="http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html"/>). The
following patch makes Ed use mkstemp instead, which is the recommended way to
create temporary files.</para>
<para>Apply the patch:</para>
<screen><userinput>patch -Np1 -i ../&ed-patch;</userinput></screen>
<para>Now prepare Ed for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And move the programs to the <filename>/bin</filename> directory, so
they can be used in the event that the <filename>/usr</filename> partition is
unavailable.</para>
<screen><userinput>mv /usr/bin/{ed,red} /bin</userinput></screen>
</sect2>
</sect1>

View File

@ -1,19 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of File</title>
<para>Prepare File for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,25 @@ Estimated required disk space: &file-compsize;</screen>
&aa-file-shortdesc;
&aa-file-dep;
&c6-file-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of File</title>
<para>Prepare File for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,30 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installing Findutils</title>
<para>Prepare Findutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr --libexecdir=/usr/bin</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>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,37 @@ Estimated required disk space: &findutils-compsize;</screen>
&aa-findutils-shortdesc;
&aa-findutils-dep;
&c6-findutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installing Findutils</title>
<para>Prepare Findutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr --libexecdir=/usr/bin</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>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,45 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Flex</title>
<para>Prepare Flex for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make bigcheck</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>There are some packages that expect to find the Lex library in
<filename>/usr/lib</filename>. Create a symlink to account for this:</para>
<screen><userinput>ln -s libfl.a /usr/lib/libl.a</userinput></screen>
<para>A few programs don't know about <userinput>flex</userinput> yet and try
to run its predecessor <userinput>lex</userinput>. To support those programs,
create a shell script named <filename>lex</filename> that calls
<userinput>flex</userinput> in Lex emulation mode:</para>
<screen><userinput>cat &gt; /usr/bin/lex &lt;&lt; "EOF"</userinput>
#!/bin/sh
# Begin /usr/bin/lex
exec /usr/bin/flex -l "$@"
# End /usr/bin/lex
<userinput>EOF
chmod 755 /usr/bin/lex</userinput></screen>
</sect2>

View File

@ -7,6 +7,51 @@ Estimated required disk space: &flex-compsize;</screen>
&aa-flex-shortdesc;
&aa-flex-dep;
&c6-flex-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Flex</title>
<para>Prepare Flex for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make bigcheck</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>There are some packages that expect to find the Lex library in
<filename>/usr/lib</filename>. Create a symlink to account for this:</para>
<screen><userinput>ln -s libfl.a /usr/lib/libl.a</userinput></screen>
<para>A few programs don't know about <userinput>flex</userinput> yet and try
to run its predecessor <userinput>lex</userinput>. To support those programs,
create a shell script named <filename>lex</filename> that calls
<userinput>flex</userinput> in Lex emulation mode:</para>
<screen><userinput>cat &gt; /usr/bin/lex &lt;&lt; "EOF"</userinput>
#!/bin/sh
# Begin /usr/bin/lex
exec /usr/bin/flex -l "$@"
# End /usr/bin/lex
<userinput>EOF
chmod 755 /usr/bin/lex</userinput></screen>
</sect2>
</sect1>

View File

@ -1,51 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gawk</title>
<para>First apply a patch to fix the following issues:</para>
<itemizedlist>
<listitem><para>Gawk's default location for some of its executables is
<filename>$prefix/libexec/awk</filename>. This location doesn't comply
with the FHS, which never even mentions a directory called
<filename>libexec</filename>. The patch makes it possible to pass a
<emphasis>--libexecdir</emphasis> switch to the configure script, so that we
can use a more appropriate location for the <userinput>grcat</userinput> and
<userinput>pwcat</userinput> binaries:
<filename>/usr/bin</filename>.</para></listitem>
<listitem><para>Gawk's default data directory is
<filename>$prefix/share/awk</filename>. But package-specific
directories should be named using the package name and version number
(for example: <filename>gawk-7.7.2.</filename>) and not simply the package
name, as there may be different versions of a package installed on the system.
The patch changes the name of the data directory to the correct
<filename>$prefix/share/gawk-&gawk-version;</filename>.</para></listitem>
<listitem><para>The patch also ensures that this data directory, including its
contents, is removed on a <emphasis>make uninstall</emphasis>.</para></listitem>
</itemizedlist>
<screen><userinput>patch -Np1 -i ../&gawk-patch;</userinput></screen>
<para>Now prepare Gawk for compilation:</para>
<screen><userinput>./configure --prefix=/usr --libexecdir=/usr/bin</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,7 +7,57 @@ Estimated required disk space: &gawk-compsize;</screen>
&aa-gawk-shortdesc;
&aa-gawk-dep;
&c6-gawk-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gawk</title>
<para>First apply a patch to fix the following issues:</para>
<itemizedlist>
<listitem><para>Gawk's default location for some of its executables is
<filename>$prefix/libexec/awk</filename>. This location doesn't comply
with the FHS, which never even mentions a directory called
<filename>libexec</filename>. The patch makes it possible to pass a
<emphasis>--libexecdir</emphasis> switch to the configure script, so that we
can use a more appropriate location for the <userinput>grcat</userinput> and
<userinput>pwcat</userinput> binaries:
<filename>/usr/bin</filename>.</para></listitem>
<listitem><para>Gawk's default data directory is
<filename>$prefix/share/awk</filename>. But package-specific
directories should be named using the package name and version number
(for example: <filename>gawk-7.7.2.</filename>) and not simply the package
name, as there may be different versions of a package installed on the system.
The patch changes the name of the data directory to the correct
<filename>$prefix/share/gawk-&gawk-version;</filename>.</para></listitem>
<listitem><para>The patch also ensures that this data directory, including its
contents, is removed on a <emphasis>make uninstall</emphasis>.</para></listitem>
</itemizedlist>
<screen><userinput>patch -Np1 -i ../&gawk-patch;</userinput></screen>
<para>Now prepare Gawk for compilation:</para>
<screen><userinput>./configure --prefix=/usr --libexecdir=/usr/bin</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,51 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of GCC</title>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>This is an older release of GCC which we are going to install for the
purpose of compiling the Linux kernel in <xref linkend="chapter08"/>. This
version is recommended
by the kernel developers when you need absolute stability. Later versions of
GCC have not received as much testing for Linux kernel compilation. Using a
later version is likely to work, however, we recommend adhering to the kernel
developer's advice and using the version here to compile your kernel.</para>
<note><para>We don't install the C++ compiler or libraries here. However, there
may be reasons why you would want to install them. More information can be found
at <ulink url="&blfs-root;view/stable/general/gcc2.html"/>.</para></note>
<para>We'll install this older release of GCC into the non-standard prefix of
<filename class="directory">/opt</filename> so as to avoid interfering with
the system GCC already installed in <filename class="directory">/usr</filename>
.</para>
<para>Apply the patches and make a small adjustment:</para>
<screen><userinput>patch -Np1 -i ../&gcc-2953-patch;
patch -Np1 -i ../&gcc-2953-no-fixinc-patch;
patch -Np1 -i ../&gcc-2953-returntype-fix-patch;
echo timestamp &gt; gcc/cstamp-h.in</userinput></screen>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-2-build
cd ../gcc-2-build</userinput></screen>
<para>Compile and install gcc:</para>
<screen><userinput>../gcc-2.95.3/configure --prefix=/opt/gcc-2.95.3 \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-shared --enable-languages=c \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix
make bootstrap
make install</userinput></screen>
</sect2>

View File

@ -5,7 +5,57 @@
<screen>Estimated build time: &gcc-2953-time;
Estimated required disk space: &gcc-2953-compsize;</screen>
&c6-gcc-2953-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of GCC</title>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>This is an older release of GCC which we are going to install for the
purpose of compiling the Linux kernel in <xref linkend="chapter08"/>. This
version is recommended
by the kernel developers when you need absolute stability. Later versions of
GCC have not received as much testing for Linux kernel compilation. Using a
later version is likely to work, however, we recommend adhering to the kernel
developer's advice and using the version here to compile your kernel.</para>
<note><para>We don't install the C++ compiler or libraries here. However, there
may be reasons why you would want to install them. More information can be found
at <ulink url="&blfs-root;view/stable/general/gcc2.html"/>.</para></note>
<para>We'll install this older release of GCC into the non-standard prefix of
<filename class="directory">/opt</filename> so as to avoid interfering with
the system GCC already installed in <filename class="directory">/usr</filename>
.</para>
<para>Apply the patches and make a small adjustment:</para>
<screen><userinput>patch -Np1 -i ../&gcc-2953-patch;
patch -Np1 -i ../&gcc-2953-no-fixinc-patch;
patch -Np1 -i ../&gcc-2953-returntype-fix-patch;
echo timestamp &gt; gcc/cstamp-h.in</userinput></screen>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-2-build
cd ../gcc-2-build</userinput></screen>
<para>Compile and install gcc:</para>
<screen><userinput>../gcc-2.95.3/configure --prefix=/opt/gcc-2.95.3 \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-shared --enable-languages=c \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-threads=posix
make bootstrap
make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,78 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of GCC</title>
<note><para>The test suite for GCC in this section is considered
<emphasis>critical</emphasis>. Our advice is to not skip it under any
circumstance.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>This time we will build both the C and the C++ compiler, so you'll have
to unpack the GCC-core <emphasis>and</emphasis> the GCC-g++ tarball -- they
will unfold into the same directory. You should likewise extract the
GCC-testsuite package. The full GCC package contains even more
compilers. Instructions for building these can be found at
<ulink url="&blfs-root;view/stable/general/gcc.html"/>.</para>
<screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
patch -Np1 -i ../&gcc-suppress-libiberty-patch;</userinput></screen>
<para>The second patch here suppresses the installation of libiberty from GCC,
as we will use the one provided by binutils instead. Be careful
<emphasis>not</emphasis> to apply the GCC specs patch from Chapter 5
here.</para>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Now prepare GCC for compilation:</para>
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/usr \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-shared --enable-threads=posix \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-__cxa_atexit --enable-clocale=gnu \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Test the results, but don't stop at errors (you'll remember the few
known ones):</para>
<screen><userinput>make -k check</userinput></screen>
<para>The test suite notes from <xref linkend="ch05-gcc-pass2"/> are still very
much appropriate here. Be sure to refer back there should you have any
doubts.</para>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Some packages expect the C PreProcessor to be installed in the
<filename>/lib</filename> directory.
To honor those packages, create this symlink:</para>
<screen><userinput>ln -s ../usr/bin/cpp /lib</userinput></screen>
<para>Many packages use the name <userinput>cc</userinput> to call the C
compiler. To satisfy those packages, create a symlink:</para>
<screen><userinput>ln -s gcc /usr/bin/cc</userinput></screen>
<note><para>At this point it is strongly recommended to repeat the sanity check
we performed earlier in this chapter. Refer back to
<xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results
are wrong, then most likely you erroneously applied the GCC Specs patch from
Chapter 5.</para></note>
</sect2>

View File

@ -7,7 +7,85 @@ Estimated required disk space: &gcc-compsize;</screen>
&aa-gcc-shortdesc;
&aa-gcc-dep;
&c6-gcc-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of GCC</title>
<note><para>The test suite for GCC in this section is considered
<emphasis>critical</emphasis>. Our advice is to not skip it under any
circumstance.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
Therefore, if you have defined any environment variables that override
default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>This time we will build both the C and the C++ compiler, so you'll have
to unpack the GCC-core <emphasis>and</emphasis> the GCC-g++ tarball -- they
will unfold into the same directory. You should likewise extract the
GCC-testsuite package. The full GCC package contains even more
compilers. Instructions for building these can be found at
<ulink url="&blfs-root;view/stable/general/gcc.html"/>.</para>
<screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
patch -Np1 -i ../&gcc-suppress-libiberty-patch;</userinput></screen>
<para>The second patch here suppresses the installation of libiberty from GCC,
as we will use the one provided by binutils instead. Be careful
<emphasis>not</emphasis> to apply the GCC specs patch from Chapter 5
here.</para>
<para>The GCC documentation recommends building GCC outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../gcc-build
cd ../gcc-build</userinput></screen>
<para>Now prepare GCC for compilation:</para>
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/usr \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-shared --enable-threads=posix \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-__cxa_atexit --enable-clocale=gnu \
&nbsp;&nbsp;&nbsp;&nbsp;--enable-languages=c,c++</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Test the results, but don't stop at errors (you'll remember the few
known ones):</para>
<screen><userinput>make -k check</userinput></screen>
<para>The test suite notes from <xref linkend="ch05-gcc-pass2"/> are still very
much appropriate here. Be sure to refer back there should you have any
doubts.</para>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>Some packages expect the C PreProcessor to be installed in the
<filename>/lib</filename> directory.
To honor those packages, create this symlink:</para>
<screen><userinput>ln -s ../usr/bin/cpp /lib</userinput></screen>
<para>Many packages use the name <userinput>cc</userinput> to call the C
compiler. To satisfy those packages, create a symlink:</para>
<screen><userinput>ln -s gcc /usr/bin/cc</userinput></screen>
<note><para>At this point it is strongly recommended to repeat the sanity check
we performed earlier in this chapter. Refer back to
<xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results
are wrong, then most likely you erroneously applied the GCC Specs patch from
Chapter 5.</para></note>
</sect2>
</sect1>

View File

@ -1,25 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gettext</title>
<para>Prepare Gettext for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so (and takes a very long time):</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,6 +7,31 @@ Estimated required disk space: &gettext-compsize;</screen>
&aa-gettext-shortdesc;
&aa-gettext-dep;
&c6-gettext-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gettext</title>
<para>Prepare Gettext for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so (and takes a very long time):</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,110 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Glibc installation</title>
<para>The Glibc build system is very well self-contained and will install
perfectly, even though our compiler specs file and linker are still pointing
at <filename>/tools</filename>. We cannot adjust the specs and linker before
the Glibc install, because the Glibc autoconf tests would then give bogus
results and thus defeat our goal of achieving a clean build.</para>
<note><para>The test suite for Glibc in this section is considered
<emphasis>critical</emphasis>. Our advice is to not skip it under any
circumstance.</para></note>
<para>Before starting to build Glibc, remember to unpack the Glibc-linuxthreads
again inside the <filename>glibc-&glibc-version;</filename> directory, and to
unset any environment variables that override the default optimization
flags.</para>
<para>Though it is a harmless message, the install stage of Glibc will
complain about the absence of <filename>/etc/ld.so.conf</filename>. Fix this
annoying little warning with:</para>
<screen><userinput>touch /etc/ld.so.conf</userinput></screen>
<para>Then apply the same patch we used previously:</para>
<screen><userinput>patch -Np1 -i ../&glibc-sscanf-patch;</userinput></screen>
<para>The Glibc documentation recommends building Glibc outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../glibc-build
cd ../glibc-build</userinput></screen>
<para>Now prepare Glibc for compilation:</para>
<screen><userinput>../glibc-&glibc-version;/configure --prefix=/usr \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-profile --enable-add-ons \
&nbsp;&nbsp;&nbsp;&nbsp;--libexecdir=/usr/bin --with-headers=/usr/include</userinput></screen>
<para>The meaning of the new configure options:</para>
<itemizedlist>
<listitem><para><userinput>--libexecdir=/usr/bin</userinput>: This will
cause the <filename>pt_chown</filename> program to be installed in the
<filename>/usr/bin</filename> directory.</para></listitem>
<listitem><para><userinput>--with-headers=/usr/include</userinput>: This
ensures that the kernel headers in <filename>/usr/include</filename> are used
for this build. If you don't pass this switch then the headers from
<filename>/tools/include</filename> are used which of course is not ideal
(although they should be identical). Using this switch has the advantage
that you will be informed immediately should you have forgotten to install the
kernel headers into <filename>/usr/include</filename>.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Test the results:</para>
<screen><userinput>make check</userinput></screen>
<para>The test suite notes from <xref linkend="ch05-glibc"/> are still very much
appropriate here. Be sure to refer back there should you have any doubts.</para>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>The locales that can make your system respond in a different language
weren't installed by the above command. Do it with this:</para>
<screen><userinput>make localedata/install-locales</userinput></screen>
<para>An alternative to running the previous command is to install only those
locales which you need or want. This can be achieved using the
<userinput>localedef</userinput> command. Information on this can be found in
the <filename>INSTALL</filename> file in the
<filename>glibc-&glibc-version;</filename> tree. However, there are a number
of locales that are essential for the tests of future packages to pass
correctly. The following instructions, in place of the install-locales
command above, will install the minimum set of locales necessary for the
tests to run successfully:</para>
<screen><userinput>mkdir -p /usr/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
<para>Finally, build the linuxthreads man pages:</para>
<screen><userinput>make -C ../&glibc-dir;/linuxthreads/man</userinput></screen>
<para>And install these pages:</para>
<screen><userinput>make -C ../&glibc-dir;/linuxthreads/man install</userinput></screen>
</sect2>

View File

@ -7,8 +7,116 @@ Estimated required disk space: &glibc-compsize;</screen>
&aa-glibc-shortdesc;
&aa-glibc-dep;
&c6-glibc-inst;
&c6-cf-glibc;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Glibc installation</title>
<para>The Glibc build system is very well self-contained and will install
perfectly, even though our compiler specs file and linker are still pointing
at <filename>/tools</filename>. We cannot adjust the specs and linker before
the Glibc install, because the Glibc autoconf tests would then give bogus
results and thus defeat our goal of achieving a clean build.</para>
<note><para>The test suite for Glibc in this section is considered
<emphasis>critical</emphasis>. Our advice is to not skip it under any
circumstance.</para></note>
<para>Before starting to build Glibc, remember to unpack the Glibc-linuxthreads
again inside the <filename>glibc-&glibc-version;</filename> directory, and to
unset any environment variables that override the default optimization
flags.</para>
<para>Though it is a harmless message, the install stage of Glibc will
complain about the absence of <filename>/etc/ld.so.conf</filename>. Fix this
annoying little warning with:</para>
<screen><userinput>touch /etc/ld.so.conf</userinput></screen>
<para>Then apply the same patch we used previously:</para>
<screen><userinput>patch -Np1 -i ../&glibc-sscanf-patch;</userinput></screen>
<para>The Glibc documentation recommends building Glibc outside of the source
directory in a dedicated build directory:</para>
<screen><userinput>mkdir ../glibc-build
cd ../glibc-build</userinput></screen>
<para>Now prepare Glibc for compilation:</para>
<screen><userinput>../glibc-&glibc-version;/configure --prefix=/usr \
&nbsp;&nbsp;&nbsp;&nbsp;--disable-profile --enable-add-ons \
&nbsp;&nbsp;&nbsp;&nbsp;--libexecdir=/usr/bin --with-headers=/usr/include</userinput></screen>
<para>The meaning of the new configure options:</para>
<itemizedlist>
<listitem><para><userinput>--libexecdir=/usr/bin</userinput>: This will
cause the <filename>pt_chown</filename> program to be installed in the
<filename>/usr/bin</filename> directory.</para></listitem>
<listitem><para><userinput>--with-headers=/usr/include</userinput>: This
ensures that the kernel headers in <filename>/usr/include</filename> are used
for this build. If you don't pass this switch then the headers from
<filename>/tools/include</filename> are used which of course is not ideal
(although they should be identical). Using this switch has the advantage
that you will be informed immediately should you have forgotten to install the
kernel headers into <filename>/usr/include</filename>.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Test the results:</para>
<screen><userinput>make check</userinput></screen>
<para>The test suite notes from <xref linkend="ch05-glibc"/> are still very much
appropriate here. Be sure to refer back there should you have any doubts.</para>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>The locales that can make your system respond in a different language
weren't installed by the above command. Do it with this:</para>
<screen><userinput>make localedata/install-locales</userinput></screen>
<para>An alternative to running the previous command is to install only those
locales which you need or want. This can be achieved using the
<userinput>localedef</userinput> command. Information on this can be found in
the <filename>INSTALL</filename> file in the
<filename>glibc-&glibc-version;</filename> tree. However, there are a number
of locales that are essential for the tests of future packages to pass
correctly. The following instructions, in place of the install-locales
command above, will install the minimum set of locales necessary for the
tests to run successfully:</para>
<screen><userinput>mkdir -p /usr/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
<para>Finally, build the linuxthreads man pages:</para>
<screen><userinput>make -C ../&glibc-dir;/linuxthreads/man</userinput></screen>
<para>And install these pages:</para>
<screen><userinput>make -C ../&glibc-dir;/linuxthreads/man install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,26 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Grep</title>
<para>Prepare Grep for compilation:</para>
<screen><userinput>./configure --prefix=/usr --bindir=/bin \
&nbsp;&nbsp;&nbsp;&nbsp;--with-included-regex</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>

View File

@ -7,6 +7,32 @@ Estimated required disk space: &grep-compsize;</screen>
&aa-grep-shortdesc;
&aa-grep-dep;
&c6-grep-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Grep</title>
<para>Prepare Grep for compilation:</para>
<screen><userinput>./configure --prefix=/usr --bindir=/bin \
&nbsp;&nbsp;&nbsp;&nbsp;--with-included-regex</userinput></screen>
<para>Compile the package:</para>
<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. Should you choose to run it, the
following command will do so:</para>
<screen><userinput>make check</userinput></screen>
<para>And install the package:</para>
<screen><userinput>make install</userinput></screen>
</sect2>
</sect1>

View File

@ -1,31 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Groff</title>
<para>Groff expects the environment variable PAGE to contain the default paper
size. For those in the United States, the command below is appropriate. If you
live elsewhere, you may want to change <emphasis>PAGE=letter</emphasis> to
<emphasis>PAGE=A4</emphasis>.</para>
<para>Prepare Groff for compilation:</para>
<screen><userinput>PAGE=letter ./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
<para>Some documentation programs, such as <userinput>xman</userinput>,
will not work work properly without the following symlinks:</para>
<screen><userinput>ln -s soelim /usr/bin/zsoelim
ln -s eqn /usr/bin/geqn
ln -s tbl /usr/bin/gtbl</userinput></screen>
</sect2>

View File

@ -7,7 +7,37 @@ Estimated required disk space: &groff-compsize;</screen>
&aa-groff-shortdesc;
&aa-groff-dep;
&c6-groff-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Groff</title>
<para>Groff expects the environment variable PAGE to contain the default paper
size. For those in the United States, the command below is appropriate. If you
live elsewhere, you may want to change <emphasis>PAGE=letter</emphasis> to
<emphasis>PAGE=A4</emphasis>.</para>
<para>Prepare Groff for compilation:</para>
<screen><userinput>PAGE=letter ./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install</userinput></screen>
<para>Some documentation programs, such as <userinput>xman</userinput>,
will not work work properly without the following symlinks:</para>
<screen><userinput>ln -s soelim /usr/bin/zsoelim
ln -s eqn /usr/bin/geqn
ln -s tbl /usr/bin/gtbl</userinput></screen>
</sect2>
</sect1>

View File

@ -1,41 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Grub</title>
<para>This package is known to behave badly when you have changed its default
optimization flags (including the -march and -mcpu options). Therefore, if you
have defined any environment variables that override default optimizations,
such as CFLAGS and CXXFLAGS, we recommend unsetting them when building
Grub.</para>
<para>Grub needs a patch to fix a compilation problem with GCC-&gcc-version;</para>
<screen><userinput>patch -Np1 -i ../&grub-patch;</userinput></screen>
<para>Prepare Grub for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install
mkdir /boot/grub
cp /usr/share/grub/i386-pc/stage{1,2} /boot/grub</userinput></screen>
<para>Replace <filename class="directory">i386-pc</filename> with whatever
directory is appropriate for your hardware.</para>
<para>The <filename class="directory">i386-pc</filename> directory also
contains a number of <filename>*stage1_5</filename> files, different ones
for different filesystems. Have a look at the ones available and copy the
appropriate ones to the <filename class="directory">/boot/grub</filename>
directory. Most people will copy the <filename>e2fs_stage1_5</filename>
and/or <filename>reiserfs_stage1_5</filename> files.</para>
</sect2>

View File

@ -7,6 +7,47 @@ Estimated required disk space: &grub-compsize;</screen>
&aa-grub-shortdesc;
&aa-grub-dep;
&c6-grub-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Grub</title>
<para>This package is known to behave badly when you have changed its default
optimization flags (including the -march and -mcpu options). Therefore, if you
have defined any environment variables that override default optimizations,
such as CFLAGS and CXXFLAGS, we recommend unsetting them when building
Grub.</para>
<para>Grub needs a patch to fix a compilation problem with GCC-&gcc-version;</para>
<screen><userinput>patch -Np1 -i ../&grub-patch;</userinput></screen>
<para>Prepare Grub for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>And install it:</para>
<screen><userinput>make install
mkdir /boot/grub
cp /usr/share/grub/i386-pc/stage{1,2} /boot/grub</userinput></screen>
<para>Replace <filename class="directory">i386-pc</filename> with whatever
directory is appropriate for your hardware.</para>
<para>The <filename class="directory">i386-pc</filename> directory also
contains a number of <filename>*stage1_5</filename> files, different ones
for different filesystems. Have a look at the ones available and copy the
appropriate ones to the <filename class="directory">/boot/grub</filename>
directory. Most people will copy the <filename>e2fs_stage1_5</filename>
and/or <filename>reiserfs_stage1_5</filename> files.</para>
</sect2>
</sect1>

View File

@ -1,34 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gzip</title>
<para>Prepare Gzip for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>The gzexe program has the location of the gzip binary hard-wired into
it. Because we later change the location of this binary, the following
command will place the new location into the gzexe binary.</para>
<screen><userinput>cp gzexe.in{,.backup}
sed 's%"BINDIR"%/bin%' gzexe.in.backup &gt; gzexe.in</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And move the programs to the <filename
class="directory">/bin</filename> directory:</para>
<screen><userinput>mv /usr/bin/gzip /bin
rm /usr/bin/{gunzip,zcat}
ln -s gzip /bin/gunzip
ln -s gzip /bin/zcat
ln -s gunzip /bin/uncompress</userinput></screen>
</sect2>

View File

@ -7,6 +7,41 @@ Estimated required disk space: &gzip-compsize;</screen>
&aa-gzip-shortdesc;
&aa-gzip-dep;
&c6-gzip-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Gzip</title>
<para>Prepare Gzip for compilation:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<para>The gzexe program has the location of the gzip binary hard-wired into
it. Because we later change the location of this binary, the following
command will place the new location into the gzexe binary.</para>
<screen><userinput>cp gzexe.in{,.backup}
sed 's%"BINDIR"%/bin%' gzexe.in.backup &gt; gzexe.in</userinput></screen>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Install the package:</para>
<screen><userinput>make install</userinput></screen>
<para>And move the programs to the <filename
class="directory">/bin</filename> directory:</para>
<screen><userinput>mv /usr/bin/gzip /bin
rm /usr/bin/{gunzip,zcat}
ln -s gzip /bin/gunzip
ln -s gzip /bin/zcat
ln -s gunzip /bin/uncompress</userinput></screen>
</sect2>
</sect1>

View File

@ -1,51 +0,0 @@
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Inetutils</title>
<para>Prepare Inetutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr --disable-syslogd \
&nbsp;&nbsp;&nbsp;&nbsp;--libexecdir=/usr/sbin --disable-logger \
&nbsp;&nbsp;&nbsp;&nbsp;--sysconfdir=/etc --localstatedir=/var \
&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
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-whois</userinput>: This option disables
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
installation of the various network servers included as part of the Inetutils
package. These servers are deemed not appropriate in a basic LFS system. Some
are insecure by nature and are only considered safe on trusted networks. More
information can be found at
<ulink url="&blfs-root;view/stable/basicnet/inetutils.html"/>. Note that better
replacements are available for many of these servers.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Install it:</para>
<screen><userinput>make install</userinput></screen>
<para>And move the <userinput>ping</userinput> program to its proper place:</para>
<screen><userinput>mv /usr/bin/ping /bin</userinput></screen>
</sect2>

View File

@ -7,6 +7,57 @@ Estimated required disk space: &inetutils-compsize;</screen>
&aa-inetutils-shortdesc;
&aa-inetutils-dep;
&c6-inetutils-inst;
<sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
<sect2>
<title>Installation of Inetutils</title>
<para>Prepare Inetutils for compilation:</para>
<screen><userinput>./configure --prefix=/usr --disable-syslogd \
&nbsp;&nbsp;&nbsp;&nbsp;--libexecdir=/usr/sbin --disable-logger \
&nbsp;&nbsp;&nbsp;&nbsp;--sysconfdir=/etc --localstatedir=/var \
&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
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-whois</userinput>: This option disables
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
installation of the various network servers included as part of the Inetutils
package. These servers are deemed not appropriate in a basic LFS system. Some
are insecure by nature and are only considered safe on trusted networks. More
information can be found at
<ulink url="&blfs-root;view/stable/basicnet/inetutils.html"/>. Note that better
replacements are available for many of these servers.</para></listitem>
</itemizedlist>
<para>Compile the package:</para>
<screen><userinput>make</userinput></screen>
<para>Install it:</para>
<screen><userinput>make install</userinput></screen>
<para>And move the <userinput>ping</userinput> program to its proper place:</para>
<screen><userinput>mv /usr/bin/ping /bin</userinput></screen>
</sect2>
</sect1>

Some files were not shown because too many files have changed in this diff Show More