Make the new book

git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/cross-chap5@11831 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Pierre Labastie 2020-05-03 21:02:51 +00:00
parent 9d719e24c3
commit efcb393343
75 changed files with 1262 additions and 1630 deletions

View File

@ -46,12 +46,10 @@
important issues you need be aware of before beginning to
work your way through <xref linkend="chapter-temporary-tools"/> and beyond.</para>
<para><xref linkend="chapter-temporary-tools"/> explains the
installation of a number of packages that will form the basic
development suite (or toolchain) which is used to build the actual
system in <xref linkend="chapter-building-system"/>. Some of these
packages are needed to resolve circular dependencies&mdash;for example,
to compile a compiler, you need a compiler.</para>
<para><xref linkend="chapter-temporary-tools"/> explains the installation of
a number of packages that are needed to resolve circular
dependencies&mdash;for example, to compile a compiler, you need a compiler.
or to unpack the tar package, you need tar.</para>
<para><xref linkend="chapter-temporary-tools"/> also shows you how to
build a first pass of the toolchain, including Binutils and GCC (first pass
@ -66,20 +64,21 @@
kernel. </para>
<para>This effort to isolate the new system from the host distribution may
seem excessive. A full technical explanation as to why this is done is provided in
<xref linkend="ch-tools-toolchaintechnotes"/>.</para>
seem excessive. A full technical explanation as to why this is done is
provided in <xref linkend="ch-tools-toolchaintechnotes"/>.</para>
<para>In <xref linkend="chapter-building-system"/>, the full LFS system is
built. The <command>chroot</command> (change root) program is used to enter
a virtual environment and start a new shell whose root directory will be
set to the LFS partition. This is very similar to rebooting and instructing
the kernel to mount the LFS partition as the root partition. The system
does not actually reboot, but instead uses <command>chroot</command> because
creating a bootable system requires additional work which is not necessary
just yet. The major advantage is that <quote>chrooting</quote> allows you
to continue using the host system while LFS is being built. While waiting
for package compilations to complete, you can continue using your computer as
normal.</para>
<para><xref linkend="chapter-building-system"/> begins with installing the
remaining packages needed to build and test the final toolchain. Then, the
full LFS system is built. But first, the <command>chroot</command> (change
root) program is used to enter a virtual environment and start a new shell
whose root directory will be set to the LFS partition. This is very similar
to rebooting and instructing the kernel to mount the LFS partition as the
root partition. The system does not actually reboot, but instead uses
<command>chroot</command> because creating a bootable system requires
additional work which is not necessary just yet. The major advantage is
that <quote>chrooting</quote> allows you to continue using the host system
while LFS is being built. While waiting for package compilations to
complete, you can continue using your computer as normal.</para>
<para>To finish the installation, the basic system configuration is set up in
<xref linkend="chapter-config"/>, and the kernel and boot loader are set

View File

@ -25,9 +25,9 @@
<itemizedlist>
<listitem>
<para>Procedures done as the root user after Section 2.4 need to
have the LFS environment variable set <emphasis>FOR THE ROOT
USER</emphasis>.</para>
<para>Procedures done as the root user after Section 2.4 need to
have the LFS environment variable set <emphasis>FOR THE ROOT
USER</emphasis>.</para>
</listitem>
</itemizedlist>
</sect2>
@ -37,14 +37,20 @@
<itemizedlist>
<listitem>
<para>The /mnt/lfs partition must be mounted.</para>
<para>The /mnt/lfs partition must be mounted.</para>
</listitem>
<listitem>
<para><emphasis>ALL</emphasis> instructions in Chapter&nbsp;5
must be done by user <emphasis>lfs</emphasis>.
A <command>su - lfs</command> needs to be done before any
task in Chapter&nbsp;5.</para>
<para>This chapter includes three parts. The first one, from
<quote>Binutils Pass1</quote> to <quote>Stripping</quote>
must be done by user <emphasis>lfs</emphasis>. A
<command>su - lfs</command> needs to be done before any task in this
part. The second part, from <quote>Changing Ownership</quote> to
<quote>Entering the Chroot Environment</quote> must be done as the
root user, with LFS set for the root user. The third part, from
<quote>Creating Directories</quote> to the end of the chapter, is done
in the chroot environment. The same procedures as for chapter 6
apply.</para>
</listitem>
<listitem>

View File

@ -25,15 +25,9 @@
are strongly recommended.</para>
<note>
<para>Experience has shown that there is little to be gained from running
the test suites in <xref linkend="chapter-temporary-tools"/>. There can be
no escaping the fact that the host system always exerts some influence on
the tests in that chapter, often causing inexplicable failures. Because
the tools built in <xref linkend="chapter-temporary-tools"/> are temporary
and eventually discarded, we do not recommend running the test suites in
<xref linkend="chapter-temporary-tools"/> for the average reader. The
instructions for running those test suites are provided for the benefit of
testers and developers, but they are strictly optional.</para>
<para>Running the test suites in <xref linkend="chapter-temporary-tools"/>
is impossible, since the programs are compiled with a cross-compiler,
so are not supposed to be able to run on the build host.</para>
</note>
<para>A common issue with running the test suites for Binutils and GCC

View File

@ -77,10 +77,10 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
<screen role="nodump"><userinput>passwd lfs</userinput></screen>
<para>Grant <systemitem class="username">lfs</systemitem> full access to
<filename class="directory">$LFS/tools</filename> by making
all directories under <filename class="directory">$LFS</filename> by making
<systemitem class="username">lfs</systemitem> the directory owner:</para>
<screen><userinput>chown -v lfs $LFS/tools</userinput></screen>
<screen><userinput>chown -v lfs $LFS/{usr,lib,var,etc,bin,sbin,lib64,tools}</userinput></screen>
<para>If a separate working directory was created as suggested, give
user <systemitem class="username">lfs</systemitem> ownership of this

View File

@ -13,7 +13,7 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="introduction.xml"/>
<!--<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="aboutlfs.xml"/>-->
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="creatingtoolsdir.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="creatingminlayout.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="addinguser.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="settingenviron.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="aboutsbus.xml"/>

View File

@ -0,0 +1,32 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-tools-creatingminlayout">
<?dbhtml filename="creatingminlayout.html"?>
<title>Creating the Minimal directory layout in LFS filesystem</title>
<para>The first task performed in the LFS partition is to create a minimal
directory hierarchy so that programs compiled in <xref
linkend="chapter-temporary-tools"/> may be installed in their final
location. This is needed so that those temporary programs be overwritten
when rebuilding them in <xref linkend="chapter-building-system"/>.</para>
<para>Create the required directory layout by running the following as
<systemitem class="username">root</systemitem>:</para>
<screen><userinput>mkdir -pv $LFS/{usr,lib,var,etc,bin,sbin,lib64}</userinput></screen>
<para>Programs in <xref linkend="chapter-temporary-tools"/> will be compiled
with a cross-compiler (more details in section <xref
linkend="ch-tools-toolchaintechnotes"/>). In order to separate this
cross-compiler from the other programs, it will be installed in a special
directory. Create this directory with:</para>
<screen><userinput>mkdir -pv $LFS/tools</userinput></screen>
</sect1>

View File

@ -11,7 +11,7 @@
<title>Introduction</title>
<para>In this chapter, we will perform a few additional tasks to prepare
for building the temporary system. We will create a directory in
for building the temporary system. We will create a set of directories in
<filename class="directory">$LFS</filename> for the installation of the
temporary tools, add an unprivileged user to reduce risk,
and create an appropriate build environment for that user. We will also

View File

@ -43,7 +43,7 @@ umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
PATH=$LFS/tools/bin:/bin:/usr/bin
export LFS LC_ALL LFS_TGT PATH</literal>
EOF</userinput></screen>
@ -61,7 +61,7 @@ EOF</userinput></screen>
be used as soon as they are installed. By switching off the hash function,
the shell will always search the <envar>PATH</envar> when a program is to
be run. As such, the shell will find the newly compiled tools in
<filename class="directory">$LFS/tools</filename> as soon as they are
<filename class="directory">~/tools</filename> as soon as they are
available without remembering a previous version of the same program in a
different location.</para>
</listitem>
@ -108,9 +108,9 @@ EOF</userinput></screen>
</varlistentry>
<varlistentry>
<term><parameter>PATH=/tools/bin:/bin:/usr/bin</parameter></term>
<term><parameter>PATH=$LFS/tools/bin:/bin:/usr/bin</parameter></term>
<listitem>
<para>By putting <filename class="directory">/tools/bin</filename> ahead of the
<para>By putting <filename class="directory">$LFS/tools/bin</filename> ahead of the
standard <envar>PATH</envar>, all the programs installed in <xref
linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
their installation. This, combined with turning off hashing, limits the risk

View File

@ -42,15 +42,13 @@
<sect2 role="installation">
<title>Installation of Bash</title>
<!--
<para>First, apply the following patch to fix various bugs that have been
addressed upstream:</para>
<screen><userinput remap="pre">patch -Np1 -i ../&bash-fixes-patch;</userinput></screen>
-->
<para>Prepare Bash for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools --without-bash-malloc</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--build=$(support/config.guess) \
--host=$LFS_TGT \
--without-bash-malloc</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
@ -72,21 +70,18 @@
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Bash test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make tests</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<para>Move the excutable to where it is expected to be:</para>
<screen><userinput remap="install">mv $LFS/usr/bin/bash $LFS/bin/bash</userinput></screen>
<para>Make a link for the programs that use <command>sh</command> for
a shell:</para>
<screen><userinput remap="install">ln -sv bash /tools/bin/sh</userinput></screen>
<screen><userinput remap="install">ln -sv bash $LFS/bin/sh</userinput></screen>
</sect2>

View File

@ -66,15 +66,14 @@ cd build</userinput></screen>
command like this: <userinput>time { ./configure ... &amp;&amp; ...
&amp;&amp; make install; }</userinput>.</para>
</note>
<!--
<note><para>The approximate build SBU values and required disk space
in Chapter&nbsp;5 does not include test suite data.</para></note>
-->
<para>Now prepare Binutils for compilation:</para>
<screen><userinput remap="configure">../configure --prefix=/tools \
<screen><userinput remap="configure">../configure --prefix=$LFS/tools \
--with-sysroot=$LFS \
--with-lib-path=/tools/lib \
--target=$LFS_TGT \
--disable-nls \
--disable-werror</userinput></screen>
@ -83,11 +82,11 @@ cd build</userinput></screen>
<title>The meaning of the configure options:</title>
<varlistentry>
<term><parameter>--prefix=/tools</parameter></term>
<term><parameter>--prefix=$LFS/tools</parameter></term>
<listitem>
<para>This tells the configure script to prepare to install the
Binutils programs in the <filename class="directory">/tools</filename>
directory.</para>
Binutils programs in the <filename
class="directory">$LFS/tools</filename> directory.</para>
</listitem>
</varlistentry>
@ -98,15 +97,15 @@ cd build</userinput></screen>
$LFS for the target system libraries as needed.</para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term><parameter>--with-lib-path=/tools/lib</parameter></term>
<term><parameter>- -with-lib-path=/tools/lib</parameter></term>
<listitem>
<para>This specifies which library path the linker should be
configured to use.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><envar>--target=$LFS_TGT</envar></term>
<listitem>
@ -140,19 +139,6 @@ cd build</userinput></screen>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. Ordinarily we would now run the
test suite, but at this early stage the test suite framework (Tcl,
Expect, and DejaGNU) is not yet in place. The benefits of running the
tests at this point are minimal since the programs from this
first pass will soon be replaced by those from the second.</para>
<para>If building on x86_64, create a symlink to ensure the sanity of
the toolchain:</para>
<screen><userinput remap="install">case $(uname -m) in
x86_64) mkdir -v /tools/lib &amp;&amp; ln -sv lib /tools/lib64 ;;
esac</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>

View File

@ -50,52 +50,24 @@ cd build</userinput></screen>
<para>Prepare Binutils for compilation:</para>
<screen><userinput remap="configure">CC=$LFS_TGT-gcc \
AR=$LFS_TGT-ar \
RANLIB=$LFS_TGT-ranlib \
../configure \
--prefix=/tools \
<screen><userinput remap="configure">../configure \
--prefix=/usr \
--build=$(../config.guess) \
--host=$LFS_TGT \
--disable-nls \
--disable-werror \
--with-lib-path=/tools/lib \
--with-sysroot</userinput></screen>
--enable-shared \
--disable-werror</userinput></screen>
<variablelist>
<title>The meaning of the new configure options:</title>
<varlistentry>
<term><parameter>CC=$LFS_TGT-gcc AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib</parameter></term>
<term><parameter>--host=$LFS_TGT</parameter></term>
<listitem>
<para>Because this is really a native build of Binutils, setting these
variables ensures that the build system uses the cross-compiler and
associated tools instead of the ones on the host system.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--with-lib-path=/tools/lib</parameter></term>
<listitem>
<para>This tells the configure script to specify the library
search path during the compilation of Binutils, resulting in
<filename class="directory">/tools/lib</filename> being passed
to the linker. This prevents the linker from searching through
library directories on the host.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--with-sysroot</parameter></term>
<listitem>
<para>This defines a default (non-existent) sysroot directory
<filename class="directory">/tools/$LFS_TGT/sys-root</filename>.
It is useful when looking for shared objects which are required by
other shared objects explicitly included on the linker's command
line. Those objects are searched into the directories listed in
<filename>&lt;sysroot&gt;/etc/ld.so.conf</filename>, and failing
that, into the linker search path, which is right. If this switch
is not given, <filename>/etc/ld.so.conf</filename> on the host
is used, that is, programs may be linked to libraries on
the host, which we want to avoid.</para>
<para>This tells the configure script that we want to build
this pass of binutils for the $LFS_TGT machine, using our just
built cross-compiler. This prevents the linker from searching
through library directories on the host.</para>
</listitem>
</varlistentry>
@ -107,41 +79,7 @@ RANLIB=$LFS_TGT-ranlib \
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<para>Now prepare the linker for the <quote>Re-adjusting</quote> phase in
the next chapter:</para>
<screen><userinput remap="adjust">make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib
cp -v ld/ld-new /tools/bin</userinput></screen>
<variablelist>
<title>The meaning of the make parameters:</title>
<varlistentry>
<term><parameter>-C ld clean</parameter></term>
<listitem>
<para>This tells the make program to remove all compiled
files in the <filename class="directory">ld</filename>
subdirectory.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>-C ld LIB_PATH=/usr/lib:/lib</parameter></term>
<listitem>
<para>This option rebuilds everything in the <filename
class="directory">ld</filename> subdirectory. Specifying the
<envar>LIB_PATH</envar> Makefile variable on the command line
allows us to override the default value of the temporary tools
and point it to the proper final path. The value of this variable
specifies the linker's default library search path. This
preparation is used in the next chapter.</para>
</listitem>
</varlistentry>
</variablelist>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -45,19 +45,31 @@
<para>Prepare Bison for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--build=$(build-aux/config.guess) \
--host=$LFS_TGT \
--docdir=/usr/share/doc/bison-&bison-version;</userinput></screen>
<variablelist>
<title>The meaning of the new configure option:</title>
<varlistentry>
<term><parameter>--docdir=/usr/share/doc/bison-&bison-version;</parameter></term>
<listitem>
<para>This tells the build system to install bison documentation
into a versioned directory.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>To test the results, issue:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -43,12 +43,26 @@
<sect2 role="installation">
<title>Installation of Bzip2</title>
<para>Apply a patch that will install the documentation for this
package:</para>
<screen><userinput remap="pre">patch -Np1 -i ../&bzip2-docs-patch;</userinput></screen>
<para>The following command ensures installation of symbolic links are
relative:</para>
<screen><userinput remap="pre">sed -i 's@\(ln -s -f \)$(PREFIX)/bin/@\1@' Makefile</userinput></screen>
<para>Ensure the man pages are installed into the correct location:</para>
<screen><userinput remap="pre">sed -i "s@(PREFIX)/man@(PREFIX)/share/man@g" Makefile</userinput></screen>
<para>The Bzip2 package does not contain a <command>configure</command>
script. There are two <filename>Makefile</filename>, one for the shared
library, and the other for the static library. Since we need both, We
do the compilation in two stages. First the shared library:</para>
<screen><userinput remap="make">make -f Makefile-libbz2_so
<screen><userinput remap="make">make CC=$LFS_TGT-gcc -f Makefile-libbz2_so
make clean</userinput></screen>
<variablelist>
@ -69,20 +83,27 @@ make clean</userinput></screen>
<para>Compile and test the package with:</para>
<screen><userinput remap="make">make</userinput></screen>
<screen><userinput remap="make">make CC=$LFS_TGT-gcc AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make PREFIX=/tools install
cp -v bzip2-shared /tools/bin/bzip2
cp -av libbz2.so* /tools/lib
ln -sv libbz2.so.1.0 /tools/lib/libbz2.so</userinput></screen>
<screen><userinput remap="install">make PREFIX=$LFS/usr install</userinput></screen>
<para>Install the shared <command>bzip2</command> binary into the
<filename class="directory">/bin</filename> directory, make some necessary
symbolic links, and clean up:</para>
<screen><userinput remap="install">cp -v bzip2-shared $LFS/bin/bzip2
cp -av libbz2.so* $LFS/lib
ln -sv ../../lib/libbz2.so.1.0 $LFS/usr/lib/libbz2.so
rm -v $LFS/usr/bin/{bunzip2,bzcat,bzip2}
ln -sv bzip2 $LFS/bin/bunzip2
ln -sv bzip2 $LFS/bin/bzcat</userinput></screen>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-bzip2" role="."/></para>

View File

@ -18,36 +18,24 @@
class="username">root</systemitem>'s environment.</para>
</note>
<para>Currently, the <filename class="directory">$LFS/tools</filename> directory
<para>Currently, the whole directory hierarchy in <filename
class="directory">$LFS</filename>
is owned by the user <systemitem class="username">lfs</systemitem>, a user
that exists only on the host system. If the <filename
class="directory">$LFS/tools</filename> directory is kept as is, the files are
that exists only on the host system. If the directories under <filename
class="directory">$LFS</filename> are kept as they are, the files are
owned by a user ID without a corresponding account. This is dangerous because
a user account created later could get this same user ID and would own the
<filename class="directory">$LFS/tools</filename> directory and all the files
therein, thus exposing these files to possible malicious manipulation.</para>
a user account created later could get this same user ID and would own all
the files under <filename class="directory">$LFS</filename>, thus exposing
these files to possible malicious manipulation.</para>
<para>To avoid this issue, you could add the <systemitem
class="username">lfs</systemitem> user to the new LFS system later when
creating the <filename>/etc/passwd</filename> file, taking care to assign it
the same user and group IDs as on the host system. Better yet, change the
ownership of the <filename class="directory">$LFS/tools</filename> directory to
ownership of the <filename class="directory">$LFS/*</filename> directories to
user <systemitem class="username">root</systemitem> by running the following
command:</para>
<screen><userinput>chown -R root:root $LFS/tools</userinput></screen>
<para>Although the <filename class="directory">$LFS/tools</filename> directory
can be deleted once the LFS system has been finished, it can be retained to build
additional LFS systems <emphasis>of the same book version</emphasis>. How best
to backup <filename class="directory">$LFS/tools</filename> is a matter of
personal preference.</para>
<caution>
<para>If you intend to keep the temporary tools for use in building future LFS
systems, <emphasis>now</emphasis> is the time to back them up. Subsequent
commands in chapter 6 will alter the tools currently in place, rendering them
useless for future builds.</para>
</caution>
<screen><userinput>chown -R root:root $LFS/{usr,lib,var,etc,bin,sbin,lib64,tools}</userinput></screen>
</sect1>

View File

@ -19,11 +19,6 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="linux-headers.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="glibc.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="libstdc++.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="binutils-pass2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gcc-pass2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="tcl.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="expect.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dejagnu.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="m4.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="ncurses.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="bash.xml"/>
@ -35,19 +30,29 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="file.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="findutils.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gawk.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gettext.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="grep.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gzip.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="make.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="patch.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="perl.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="python.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="sed.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="tar.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="texinfo.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="util-linux.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="xz.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="binutils-pass2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gcc-pass2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="stripping.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="changingowner.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="kernfs.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="chroot.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="creatingdirs.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="createfiles.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="libstdc++-pass2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="gettext.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="perl.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="python.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="texinfo.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="util-linux.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="tcl.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="expect.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dejagnu.xml"/>
</chapter>

View File

@ -5,22 +5,24 @@
%general-entities;
]>
<sect1 id="ch-system-chroot">
<sect1 id="ch-tools-chroot">
<?dbhtml filename="chroot.html"?>
<title>Entering the Chroot Environment</title>
<para>It is time to enter the chroot environment to begin building and
installing the final LFS system. As user <systemitem
<para>Now that all the packages which depend on themselves for being built
are on the system, it is time to enter the chroot environment to finish
installing the remaining temporary tools. This environment will be in use
also for installing the final system. As user <systemitem
class="username">root</systemitem>, run the following command to enter the
realm that is, at the moment, populated with only the temporary tools:</para>
<screen role="nodump"><userinput>chroot "$LFS" /tools/bin/env -i \
<screen role="nodump"><userinput>chroot "$LFS" /usr/bin/env -i \
HOME=/root \
TERM="$TERM" \
PS1='(lfs chroot) \u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h</userinput></screen>
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
/bin/bash --login +h</userinput></screen>
<para>The <parameter>-i</parameter> option given to the <command>env</command>
command will clear all variables of the chroot environment. After that, only
@ -39,8 +41,8 @@
<filename class="directory">$LFS</filename> is now the root
(<filename class="directory">/</filename>) directory.</para>
<para>Notice that <filename class="directory">/tools/bin</filename> comes last
in the <envar>PATH</envar>. This means that a temporary tool will no longer be
<para>Notice that <filename class="directory">/tools/bin</filename> is not
anymore in the <envar>PATH</envar>. This means that a temporary tool will no longer be
used once its final version is installed. This occurs when the shell does not
<quote>remember</quote> the locations of executed binaries&mdash;for this
reason, hashing is switched off by passing the <parameter>+h</parameter> option

View File

@ -45,7 +45,11 @@
<para>Prepare Coreutils for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools --enable-install-program=hostname</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess) \
--enable-install-program=hostname \
--enable-no-install-program=kill,uptime</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
@ -64,20 +68,9 @@
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Coreutils test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make RUN_EXPENSIVE_TESTS=yes check</userinput></screen>
<para>The <parameter>RUN_EXPENSIVE_TESTS=yes</parameter> parameter tells the
test suite to run several additional tests that are considered
relatively expensive (in terms of CPU power and memory usage) on some
platforms, but generally are not a problem on Linux.</para>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<!--
<para>The above command refuses to install <filename>su</filename>
because the program cannot be installed setuid root as a non-privileged
@ -86,6 +79,19 @@
<screen><userinput remap="install">cp -v src/su /tools/bin</userinput></screen>
-->
<para>Move programs to their final expected locations. Although this is
not necessary in this temporary environment, we must do so because some
programs harcode executable locations:</para>
<screen><userinput remap="install">mv -v $LFS/usr/bin/{cat,chgrp,chmod,chown,cp,date,dd,df,echo} $LFS/bin
mv -v $LFS/usr/bin/{false,ln,ls,mkdir,mknod,mv,pwd,rm} $LFS/bin
mv -v $LFS/usr/bin/{rmdir,stty,sync,true,uname} $LFS/bin
mv -v $LFS/usr/bin/chroot $LFS/usr/sbin
mkdir -pv $LFS/usr/share/man/man8
mv -v $LFS/usr/share/man/man1/chroot.1 $LFS/usr/share/man/man8/chroot.8
sed -i s/\"1\"/\"8\"/1 $LFS/usr/share/man/man8/chroot.8
mv -v $LFS/usr/bin/{head,nice,sleep,touch} $LFS/bin</userinput></screen>
</sect2>
<sect2 role="content">

View File

@ -5,203 +5,35 @@
%general-entities;
]>
<sect1 id="ch-system-createfiles">
<sect1 id="ch-tools-createfiles">
<?dbhtml filename="createfiles.html"?>
<title>Creating Essential Files and Symlinks</title>
<indexterm zone="ch-system-createfiles">
<indexterm zone="ch-tools-createfiles">
<primary sortas="e-/etc/passwd">/etc/passwd</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<indexterm zone="ch-tools-createfiles">
<primary sortas="e-/etc/group">/etc/group</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<indexterm zone="ch-tools-createfiles">
<primary sortas="e-/var/run/utmp">/var/run/utmp</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<indexterm zone="ch-tools-createfiles">
<primary sortas="e-/var/log/btmp">/var/log/btmp</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<indexterm zone="ch-tools-createfiles">
<primary sortas="e-/var/log/lastlog">/var/log/lastlog</primary>
</indexterm>
<indexterm zone="ch-system-createfiles">
<indexterm zone="ch-tools-createfiles">
<primary sortas="e-/var/log/wtmp">/var/log/wtmp</primary>
</indexterm>
<para>Some programs use hard-wired paths to programs which do not exist yet.
In order to satisfy these programs, create a number of symbolic links which
will be replaced by real files throughout the course of this chapter after the
software has been installed:</para>
<screen><userinput>ln -sv /tools/bin/{bash,cat,chmod,dd,echo,ln,mkdir,pwd,rm,stty,touch} /bin
ln -sv /tools/bin/{env,install,perl,printf} /usr/bin
ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib
ln -sv /tools/lib/libstdc++.{a,so{,.6}} /usr/lib
ln -sv /tools/lib/libfl.so* /usr/lib
ln -sv bash /bin/sh
for lib in blkid mount uuid fdisk
do
ln -sv /tools/lib/lib$lib.so* /usr/lib
sed 's|/tools|/usr|' /tools/lib/pkgconfig/${lib}.pc \
&gt; /usr/lib/pkgconfig/${lib}.pc
done
for incdir in blkid libmount uuid libfdisk
do
ln -svf /tools/include/$incdir /usr/include
done</userinput></screen>
<variablelist>
<title>The purpose of each link:</title>
<varlistentry>
<term><parameter><filename>/bin/bash</filename></parameter></term>
<listitem>
<para>Many <command>bash</command> scripts specify
<filename>/bin/bash</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/cat</filename></parameter></term>
<listitem>
<para>This pathname is hard-coded into Glibc's configure script.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/dd</filename></parameter></term>
<listitem>
<para>The path to <filename>dd</filename> will be hard-coded into the
<filename>/usr/bin/libtool</filename> utility.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/echo</filename></parameter></term>
<listitem>
<para>This is to satisfy one of the tests in Glibc's test suite, which
expects <filename>/bin/echo</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/usr/bin/env</filename></parameter></term>
<listitem>
<para>This pathname is hard-coded into some packages build procedures.
<!-- systemd This may not be needed if we move sysd to the end--></para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/usr/bin/install</filename></parameter></term>
<listitem>
<para>The path to <filename>install</filename> will be hard-coded into
the <filename>/usr/lib/bash/Makefile.inc</filename> file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/ln</filename></parameter></term>
<listitem>
<para>The path to <filename>ln</filename> will be hard-coded into the
<filename>/usr/lib/perl5/&perl-version;/&lt;target-triplet&gt;/Config_heavy.pl</filename>
file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/pwd</filename></parameter></term>
<listitem>
<para>Some <command>configure</command> scripts, particularly Glibc's,
have this pathname hard-coded.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/rm</filename></parameter></term>
<listitem>
<para>The path to <filename>rm</filename> will be hard-coded into the
<filename>/usr/lib/perl5/&perl-version;/&lt;target-triplet&gt;/Config_heavy.pl</filename>
file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/stty</filename></parameter></term>
<listitem>
<para>This pathname is hard-coded into Expect, therefore it is needed
for Binutils and GCC test suites to pass.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/usr/bin/perl</filename></parameter></term>
<listitem>
<para>Many Perl scripts hard-code this path to the
<command>perl</command> program.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/usr/lib/libgcc_s.so{,.1}</filename></parameter></term>
<listitem>
<para>Glibc needs this for the pthreads library to work.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/usr/lib/libstdc++{,.6}</filename></parameter></term>
<listitem>
<para>This is needed by several tests in Glibc's test suite, as well as
for C++ support in GMP.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter><filename>/bin/sh</filename></parameter></term>
<listitem>
<para>Many shell scripts hard-code <filename>/bin/sh</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<parameter><filename>/usr/lib/libfl.so*</filename></parameter>
</term>
<listitem>
<para>This link allows binutils to find the flex library, and to
build enhanced versions of ar and ranlib.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<parameter>
<filename>/usr/lib/lib{blkid,fdisk,mount,uuid}.so*</filename>,
<filename>/usr/include/{blkid,libfdisk,libmount,uuid}</filename>,
<filename>/usr/lib/pkgconfig/{blkid,fdisk,mount,uuid}.pc</filename>
</parameter>
</term>
<listitem>
<para>These links and files allow
<phrase revision="sysv">eudev</phrase>
<phrase revision="systemd">systemd</phrase> to find the
util-linux libraries installed in chapter 5, without creating
wrong references to /tools. The uuid library is also needed for
building a python module.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Historically, Linux maintains a list of the mounted file systems in the
file <filename>/etc/mtab</filename>. Modern kernels maintain this list
internally and exposes it to the user via the <filename
@ -313,7 +145,7 @@ users:x:999:</literal>
EOF</userinput></screen>
<para>The created groups are not part of any standard&mdash;they are groups
decided on in part by the requirements of the Udev configuration in this
decided on in part by the requirements of the Udev configuration in the next
chapter, and in part by common convention employed by a number of existing
Linux distributions. In addition, some test suites rely on specific users
or groups. The Linux Standard Base (LSB, available at <ulink
@ -325,13 +157,12 @@ EOF</userinput></screen>
rather use the group's name.</para>
<para>To remove the <quote>I have no name!</quote> prompt, start a new
shell. Since a full Glibc was installed in <xref
linkend="chapter-temporary-tools"/> and the
shell. Since the
<filename>/etc/passwd</filename> and <filename>/etc/group</filename>
files have been created, user name and group name resolution will now
work:</para>
<screen role="nodump"><userinput>exec /tools/bin/bash --login +h</userinput></screen>
<screen role="nodump"><userinput>exec /bin/bash --login +h</userinput></screen>
<para>Note the use of the <parameter>+h</parameter> directive. This tells
<command>bash</command> not to use its internal path hashing. Without this

View File

@ -5,28 +5,22 @@
%general-entities;
]>
<sect1 id="ch-system-creatingdirs">
<sect1 id="ch-tools-creatingdirs">
<?dbhtml filename="creatingdirs.html"?>
<title>Creating Directories</title>
<para>It is time to create some structure in the LFS file system. Create a
standard directory tree by issuing the following commands:</para>
<para>It is time to create the full structure in the LFS file system. Create
a standard directory tree by issuing the following commands:</para>
<screen><userinput>mkdir -pv /{bin,boot,etc/{opt,sysconfig},home,lib/firmware,mnt,opt}
mkdir -pv /{media/{floppy,cdrom},sbin,srv,var}
mkdir -pv /{media/{floppy,cdrom},srv,var}
install -dv -m 0750 /root
install -dv -m 1777 /tmp /var/tmp
mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src}
mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}
mkdir -v /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -v /usr/libexec
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv /usr/{,local/}share/man/man{1..8}
mkdir -v /usr/lib/pkgconfig
case $(uname -m) in
x86_64) mkdir -v /lib64 ;;
esac
mkdir -v /var/{log,mail,spool}
ln -sv /run /var/run

View File

@ -44,11 +44,16 @@
<para>Prepare DejaGNU for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr
makeinfo --html --no-split -o doc/dejagnu.html doc/dejagnu.texi
makeinfo --plaintext -o doc/dejagnu.txt doc/dejagnu.texi</userinput></screen>
<para>Build and install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make install
install -v -dm755 /usr/share/doc/dejagnu-&dejagnu-version;
install -v -m644 doc/dejagnu.{html,txt} \
/usr/share/doc/dejagnu-&dejagnu-version;</userinput></screen>
<para>To test the results, issue:</para>

View File

@ -45,21 +45,15 @@
<para>Prepare Diffutils for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr --host=$LFS_TGT</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Diffutils test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -48,34 +48,29 @@
<sect2 role="installation">
<title>Installation of Expect</title>
<para>First, force Expect's configure script to use <filename>/bin/stty</filename>
instead of a <filename>/usr/local/bin/stty</filename> it may find on the host system.
This will ensure that our test suite tools remain sane for the final builds of our
toolchain:</para>
<para>Prepare Expect for compilation:</para>
<screen><userinput remap="pre">cp -v configure{,.orig}
sed 's:/usr/local/bin:/bin:' configure.orig &gt; configure</userinput></screen>
<para>Now prepare Expect for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools \
--with-tcl=/tools/lib \
--with-tclinclude=/tools/include</userinput></screen>
<screen><userinput remap="configure">
./configure --prefix=/usr \
--with-tcl=/usr/lib \
--enable-shared \
--mandir=/usr/share/man \
--with-tclinclude=/usr/include</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<varlistentry>
<term><parameter>--with-tcl=/tools/lib</parameter></term>
<term><parameter>--with-tcl=/usr/lib</parameter></term>
<listitem>
<para>This ensures that the configure script finds the Tcl
installation in the temporary tools location instead of possibly
locating an existing one on the host system.</para>
<para>This parameter is needed to tell the
<command>configure</command> where the
<command>tclConfig.sh</command> is located.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--with-tclinclude=/tools/include</parameter></term>
<term><parameter>--with-tclinclude=/usr/include</parameter></term>
<listitem>
<para>This explicitly tells Expect where to find Tcl's internal
headers. Using this option avoids conditions where
@ -90,33 +85,10 @@ sed 's:/usr/local/bin:/bin:' configure.orig &gt; configure</userinput></screen>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Expect test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make test</userinput></screen>
<para>Note that the Expect test suite is known to experience failures under
certain host conditions that are not within our control. Therefore,
test suite failures here are not surprising and are not considered
critical.</para>
<para>Install the package:</para>
<screen><userinput remap="install">make SCRIPTS="" install</userinput></screen>
<variablelist>
<title>The meaning of the make parameter:</title>
<varlistentry>
<term><parameter>SCRIPTS=""</parameter></term>
<listitem>
<para>This prevents installation of the supplementary Expect
scripts, which are not needed.</para>
</listitem>
</varlistentry>
</variablelist>
<screen><userinput remap="install">make install
ln -svf expect&expect-version;/libexpect&expect-version;.so /usr/lib</userinput></screen>
</sect2>

View File

@ -45,29 +45,28 @@
<para>Prepare File for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT</userinput></screen>
<!-- devs: if using - -build here, the build system wants to compile
the signature file with "file" on the build system, but stops if it is not
the same version. One possibility would be to build "file" on the build
system first, but it is simpler to have the system think it is not
cross-compiling, and use the just built "file". -->
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the File test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-file" role="."/></para>
<para>Details on this package are located in<!-- TODO
<xref linkend="contents-file" role="."/> --></para>
</sect2>

View File

@ -42,30 +42,25 @@
<sect2 role="installation">
<title>Installation of Findutils</title>
<!--
<para>First, make some fixes required by glibc-2.28:</para>
<screen><userinput remap="pre">sed -i 's/IO_ftrylockfile/IO_EOF_SEEN/' gl/lib/*.c
sed -i '/unistd/a #include &lt;sys/sysmacros.h&gt;' gl/lib/mountlist.c
echo "#define _IO_IN_BACKUP 0x100" >> gl/lib/stdio-impl.h</userinput></screen>
-->
<para>Prepare Findutils for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess)</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Findutils test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<para>Move the excutable to its final expected location:</para>
<screen><userinput remap="install">mv -v $LFS/usr/bin/find $LFS/bin
sed -i 's|find:=${BINDIR}|find:=/bin|' $LFS/usr/bin/updatedb</userinput></screen>
</sect2>

View File

@ -45,19 +45,37 @@
<para>Prepare Flex for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess) \
--disable-bootstrap \
--docdir=/usr/share/doc/flex-&flex-version;</userinput></screen>
<variablelist>
<title>The meaning of the new configure option:</title>
<varlistentry>
<term><parameter>--disable-bootstrap</parameter></term>
<listitem>
<para>Normally, building flex is done in two stages. A first
programs, which is used to generate the source of a second one,
which is then compiled. When using cross-compilation, the first
program is generated on the build systemd. However, due to a bug
in configure, the presence of some funciton is tested only on the
host system. If this function is not found on the build system, the
build fails. This can be prevented by disabling the two stage
build.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>To test the results, issue:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -43,23 +43,23 @@
<sect2 role="installation">
<title>Installation of Gawk</title>
<para>First, ensure some unneeded files are not installed:</para>
<screen><userinput remap="pre">sed -i 's/extras//' Makefile.in</userinput></screen>
<para>Prepare Gawk for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(./config.guess)</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Gawk test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -43,7 +43,7 @@
<sect2 role="installation">
<title>Installation of Cross GCC</title>
<para>GCC now requires the GMP, MPFR and MPC packages. As these packages may
<para>GCC requires the GMP, MPFR and MPC packages. As these packages may
not be included in your host distribution, they will be built with
GCC. Unpack each package into the GCC source directory and rename the
resulting directories so the GCC build procedures will automatically
@ -62,42 +62,7 @@ mv -v gmp-&gmp-version; gmp
tar -xf ../mpc-&mpc-version;.tar.gz
mv -v mpc-&mpc-version; mpc</userinput></screen>
<para>The following command will change the location of GCC's default
dynamic linker to use the one installed in <filename
class="directory">/tools</filename>. It also removes <filename
class="directory">/usr/include</filename> from GCC's include search path.
Issue:</para>
<screen><userinput remap="pre">for file in gcc/config/{linux,i386/linux{,64}}.h
do
cp -uv $file{,.orig}
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&amp;@g' \
-e 's@/usr@/tools@g' $file.orig &gt; $file
echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' &gt;&gt; $file
touch $file.orig
done</userinput></screen>
<para>In case the above seems hard to follow, let's break it down a bit.
First we copy the files <filename>gcc/config/linux.h</filename>,
<filename>gcc/config/i386/linux.h</filename>, and
<filename>gcc/config/i386/linux64.h</filename> to a file of
the same name but with an added suffix of <quote>.orig</quote>. Then the
first sed expression prepends <quote>/tools</quote> to every instance of
<quote>/lib/ld</quote>, <quote>/lib64/ld</quote> or
<quote>/lib32/ld</quote>, while the second one replaces hard-coded
instances of <quote>/usr</quote>. Next, we add our define statements which
alter the default startfile prefix to the end of the file. Note that the
trailing <quote>/</quote> in <quote>/tools/lib/</quote> is required.
Finally, we use <command>touch</command> to update the timestamp on the
copied files. When used in conjunction with <command>cp -u</command>, this
prevents unexpected changes to the original files in case the commands are
inadvertently run twice.</para>
<para>Finally, on x86_64 hosts, set the default directory name for
<para>On x86_64 hosts, set the default directory name for
64-bit libraries to <quote>lib</quote>:</para>
<screen><userinput remap="pre">case $(uname -m) in
@ -107,19 +72,6 @@ done</userinput></screen>
;;
esac</userinput></screen>
<!--
<para>GCC doesn't detect stack protection correctly, which causes problems
for the build of Glibc-&glibc-version;, so fix that by issuing the following
command:</para>
<screen><userinput remap="pre">sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure</userinput></screen>
-->
<!--
<para>Also fix a problem identified upstream:</para>
<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&amp;\&amp; \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen>
-->
<para>The GCC documentation recommends building GCC
in a dedicated build directory:</para>
@ -130,13 +82,12 @@ cd build</userinput></screen>
<screen><userinput remap="configure">../configure \
--target=$LFS_TGT \
--prefix=/tools \
--prefix=$LFS/tools \
--with-glibc-version=2.11 \
--with-sysroot=$LFS \
--with-newlib \
--without-headers \
--with-local-prefix=/tools \
--with-native-system-header-dir=/tools/include \
--enable-initfini-array \
--disable-nls \
--disable-shared \
--disable-multilib \
@ -180,36 +131,12 @@ cd build</userinput></screen>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--with-local-prefix=/tools</parameter></term>
<listitem>
<para>The local prefix is the location in the system that GCC will search
for locally installed include files. The default is <filename>/usr/local</filename>.
Setting this to <filename>/tools</filename> helps keep the host location of
<filename>/usr/local</filename> out of this GCC's search path.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--with-native-system-header-dir=/tools/include</parameter></term>
<listitem>
<para>By default, GCC searches <filename>/usr/include</filename> for
system headers. In conjunction with the sysroot switch, this would
normally translate to <filename>$LFS/usr/include</filename>. However
the headers that will be installed in the next two sections will go
to <filename>$LFS/tools/include</filename>. This switch ensures that
gcc will find them correctly. In the second pass of GCC, this same
switch will ensure that no headers from the host system are
found.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-shared</parameter></term>
<listitem>
<para>This switch forces GCC to link its internal libraries
statically. We do this to avoid possible issues with the host
system.</para>
statically. We need this because the shared libraries require glibc,
which is not yet installed on the target system.</para>
</listitem>
</varlistentry>
@ -249,26 +176,25 @@ cd build</userinput></screen>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. At this point, the test suite would
normally be run, but, as mentioned before, the test suite framework is
not in place yet. The benefits of running the tests at this point
are minimal since the programs from this first pass will soon be
replaced.</para>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<!--
<para>Using <parameter>- -disable-shared</parameter> means that the
<filename>libgcc_eh.a</filename> file isn't created and installed. The
Glibc package depends on this library as it uses
<parameter>-lgcc_eh</parameter> within its build system. This dependency
can be satisfied by creating a symlink to <filename>libgcc.a</filename>,
since that file will end up containing the objects normally contained in
<filename>libgcc_eh.a</filename>:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">ln -sv libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&amp;_eh/'`</userinput></screen>
-->
<para>This build of GCC has installed a couple of internal system
headers. Normally one of them, <filename>limits.h</filename>, would in turn
include the corresponding system <filename>limits.h</filename> header, in
this case, <filename>$LFS/usr/include/limits.h</filename>. However, at the
time of this build of gcc <filename>$LFS/usr/include/limits.h</filename>
does not exist, so the internal header that has just been installed is a
partial, self-contained file and does not include the extended features of
the system header. This is adequate for building glibc, but the full
internal header will be needed later. Create a full version of the internal
header using a command that is identical to what the GCC build system does
in normal circumstances:</para>
<screen><userinput remap="install">cd ..
cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \
`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/install-tools/include/limits.h</userinput></screen>
</sect2>
<sect2 role="content">

View File

@ -54,23 +54,6 @@ mv -v gmp-&gmp-version; gmp
tar -xf ../mpc-&mpc-version;.tar.gz
mv -v mpc-&mpc-version; mpc</userinput></screen>
<para>Once again, change the location of GCC's default dynamic linker to
use the one installed in <filename
class="directory">/tools</filename>.</para>
<screen><userinput remap="pre">for file in gcc/config/{linux,i386/linux{,64}}.h
do
cp -uv $file{,.orig}
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&amp;@g' \
-e 's@/usr@/tools@g' $file.orig &gt; $file
echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' &gt;&gt; $file
touch $file.orig
done</userinput></screen>
<para>If building on x86_64, change the default directory name for 64-bit
libraries to <quote>lib</quote>:</para>
@ -81,84 +64,62 @@ done</userinput></screen>
;;
esac</userinput></screen>
<para>Our first build of GCC has installed a couple of internal system
headers. Normally one of them, <filename>limits.h</filename>, will in turn
include the corresponding system <filename>limits.h</filename> header, in
this case, <filename>/tools/include/limits.h</filename>. However, at the
time of the first build of gcc <filename>/tools/include/limits.h</filename>
did not exist, so the internal header that GCC installed is a partial,
self-contained file and does not include the extended features of the
system header. This was adequate for building the temporary libc, but this
build of GCC now requires the full internal header. Create a full version
of the internal header using a command that is identical to what the GCC
build system does in normal circumstances:</para>
<screen><userinput remap="pre">cat gcc/limitx.h gcc/glimits.h gcc/limity.h &gt; \
`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h</userinput></screen>
<!--
<para>For x86 machines, the limited number of registers is a bottleneck
for the system. Free one up by not using a frame pointer that is not
needed:</para>
<screen><userinput remap="pre">case `uname -m` in
i?86) sed -i 's/^T_CFLAGS =$/&amp; -fomit-frame-pointer/' gcc/Makefile.in ;;
esac</userinput></screen>
-->
<para>Create a separate build directory again:</para>
<screen><userinput remap="pre">mkdir -v build
cd build</userinput></screen>
<para>Create a symlink that allos libgcc to be built with posix threads
support:</para>
<screen><userinput remap="pre">mkdir -pv $LFS_TGT/libgcc
ln -s ../../../libgcc/gthr-posix.h $LFS_TGT/libgcc/gthr-default.h</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 for compilation:</para>
<screen><userinput remap="configure">CC=$LFS_TGT-gcc \
CXX=$LFS_TGT-g++ \
AR=$LFS_TGT-ar \
RANLIB=$LFS_TGT-ranlib \
../configure \
--prefix=/tools \
--with-local-prefix=/tools \
--with-native-system-header-dir=/tools/include \
--enable-languages=c,c++ \
--disable-libstdcxx-pch \
<screen><userinput remap="configure">../configure \
--build=$(../config.guess) \
--host=$LFS_TGT \
--prefix=/usr \
CC_FOR_TARGET=$LFS_TGT-gcc \
--with-build-sysroot=$LFS \
--enable-initfini-array \
--disable-nls \
--disable-multilib \
--disable-bootstrap \
--disable-libgomp</userinput></screen>
--disable-decimal-float \
--disable-libatomic \
--disable-libgomp \
--disable-libquadmath \
--disable-libssp \
--disable-libvtv \
--disable-libstdcxx \
--enable-languages=c,c++</userinput></screen>
<variablelist>
<title>The meaning of the new configure options:</title>
<title>The meaning of the new configure options:</title><!-- WIP -->
<varlistentry>
<term><parameter>--enable-languages=c,c++</parameter></term>
<term><parameter>-with-build-sysroot=$LFS</parameter></term>
<listitem>
<para>This option ensures that both the C and C++ compilers are
built.</para>
<para>Normally, using <parameter>--host=</parameter> ensures that
a cross-compiler is used for building gcc, and that compiler knows
that it has to look for headers and libraries in <filename
class="directory">$LFS</filename>. But the build system of GCC uses
other tools, which are not aware of this location. This switch is
needed to have them find the needed files in <filename
class="directory">$LFS</filename>, and not on the host.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-libstdcxx-pch</parameter></term>
<term><parameter>--enable-initfini-array</parameter></term>
<listitem>
<para>Do not build the pre-compiled header (PCH) for
<filename class="libraryfile">libstdc++</filename>. It takes up a
lot of space, and we have no use for it.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-bootstrap</parameter></term>
<listitem>
<para>For native builds of GCC, the default is to do a "bootstrap"
build. This does not 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. The second and third
iterations are compared to make sure it can reproduce itself
flawlessly. This also implies that it was compiled correctly.
However, the LFS build method should provide a solid compiler
without the need to bootstrap each time.</para>
<para>This option is automatically enabled when building a native
compiler with a native compiler on x86. But here, we build with
a cross compiler, so we need to explicitely set this option.</para>
</listitem>
</varlistentry>
@ -170,7 +131,7 @@ RANLIB=$LFS_TGT-ranlib \
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<para>As a finishing touch, create a symlink. Many programs and scripts
run <command>cc</command> instead of <command>gcc</command>, which is
@ -179,45 +140,7 @@ RANLIB=$LFS_TGT-ranlib \
<command>cc</command> leaves the system administrator free to decide
which C compiler to install:</para>
<screen><userinput remap="install">ln -sv gcc /tools/bin/cc</userinput></screen>
<caution>
<para>At this point, it is imperative to stop and ensure that the basic
functions (compiling and linking) of the new toolchain are working as
expected. To perform a sanity check, run the following commands:</para>
<screen><userinput>echo 'int main(){}' &gt; dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'</userinput></screen>
<para>If everything is working correctly, there should be no errors,
and the output of the last command will be of the form:</para>
<screen><computeroutput>[Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
<para>Note that the dynamic linker will be /tools/lib/ld-linux.so.2
for 32-bit machines.</para>
<para>If the output is not shown as above or there was no output at all,
then something is wrong. Investigate and retrace the steps to find out
where the problem is and correct it. This issue must be resolved before
continuing on. First, perform the sanity check again, using
<command>gcc</command> instead of <command>cc</command>. If this works,
then the <filename class="symlink">/tools/bin/cc</filename> symlink is
missing. Install the symlink as per above.
Next, ensure that the <envar>PATH</envar> is correct. This
can be checked by running <command>echo $PATH</command> and verifying that
<filename class="directory">/tools/bin</filename> is at the head of the
list. If the <envar>PATH</envar> is wrong it could mean that you are not
logged in as user <systemitem class="username">lfs</systemitem> or that
something went wrong back in <xref linkend="ch-preps-settingenviron"
role="."/></para>
<para>Once all is well, clean up the test files:</para>
<screen><userinput>rm -v dummy.c a.out</userinput></screen>
</caution>
<screen><userinput remap="install">ln -sv gcc $LFS/usr/bin/cc</userinput></screen>
</sect2>

View File

@ -81,9 +81,9 @@
<listitem>
<para>Place all the sources and patches in a directory that will be
accessible from the chroot environment such as
<filename class="directory">/mnt/lfs/sources/</filename>. Do
<filename class="directory">/mnt/lfs/sources/</filename>.<!-- Do
<emphasis>not</emphasis> put sources in
<filename class="directory">/mnt/lfs/tools/</filename>.</para>
<filename class="directory">/mnt/lfs/tools/</filename>. --></para>
</listitem>
<listitem>
<para>Change to the sources directory.</para>

View File

@ -52,16 +52,7 @@
<variablelist>
<title>The meaning of the configure option:</title>
<!--
<varlistentry>
<term><parameter>EMACS="no"</parameter></term>
<listitem>
<para>This prevents the configure script from determining where to
install Emacs Lisp files as the test is known to hang on some hosts.
</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><parameter>--disable-shared</parameter></term>
<listitem>
@ -76,14 +67,10 @@
<screen><userinput remap="make">make</userinput></screen>
<para>
Due to the limited environment, running the test suite at this stage
is not recommended.</para>
<para>Install the <command>msgfmt</command>, <command>msgmerge</command> and
<command>xgettext</command> programs:</para>
<screen><userinput remap="install">cp -v gettext-tools/src/{msgfmt,msgmerge,xgettext} /tools/bin</userinput></screen>
<screen><userinput remap="install">cp -v gettext-tools/src/{msgfmt,msgmerge,xgettext} /usr/bin</userinput></screen>
</sect2>

View File

@ -43,6 +43,19 @@
<sect2 role="installation">
<title>Installation of Glibc</title>
<para>First, create two symbolic links, which are needed for proper
operation of the dynamic library loader:</para>
<screen><userinput remap="pre">ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3</userinput></screen>
<para>Some of the Glibc programs use the non-FHS compliant
<filename class="directory">/var/db</filename> directory to store their
runtime data. Apply the following patch to make such programs store their
runtime data in the FHS-compliant locations:</para>
<screen><userinput remap="pre">patch -Np1 -i ../glibc-&glibc-version;-fhs-1.patch</userinput></screen>
<para>The Glibc documentation recommends building Glibc
in a dedicated build directory:</para>
@ -52,11 +65,12 @@ cd build</userinput></screen>
<para>Next, prepare Glibc for compilation:</para>
<screen><userinput remap="configure">../configure \
--prefix=/tools \
--prefix=/usr \
--host=$LFS_TGT \
--build=$(../scripts/config.guess) \
--enable-kernel=&min-kernel; \
--with-headers=/tools/include</userinput></screen>
--with-headers=$LFS/usr/include \
libc_cv_slibdir=/lib</userinput></screen>
<!--
libc_cv_forced_unwind=yes \
libc_cv_c_cleanup=yes</userinput></screen> -->
@ -68,7 +82,7 @@ cd build</userinput></screen>
<term><parameter>--host=$LFS_TGT, --build=$(../scripts/config.guess)</parameter></term>
<listitem>
<para>The combined effect of these switches is that Glibc's build system
configures itself to cross-compile, using the cross-linker and
configures itself to be cross-compiled, using the cross-linker and
cross-compiler in <filename class="directory">/tools</filename>.</para>
</listitem>
</varlistentry>
@ -83,26 +97,22 @@ cd build</userinput></screen>
</varlistentry>
<varlistentry>
<term><parameter>--with-headers=/tools/include</parameter></term>
<term><parameter>--with-headers=$LFS/usr/include</parameter></term>
<listitem>
<para>This tells Glibc to compile itself against the headers recently
installed to the tools directory, so that it knows exactly what
installed to the usr/include directory, so that it knows exactly what
features the kernel has and can optimize itself accordingly.</para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term><parameter>libc_cv_forced_unwind=yes</parameter></term>
<term><parameter>libc_cv_slibdir=/lib</parameter></term>
<listitem>
<para>The linker installed during
<xref linkend="ch-tools-binutils-pass1"/> was cross-compiled and as
such cannot be used until Glibc has been installed. This means that
the configure test for force-unwind support will fail, as it relies on
a working linker. The libc_cv_forced_unwind=yes variable is passed in
order to inform <command>configure</command> that force-unwind
support is available without it having to run the test.</para>
<para>This ensures that the library is installed in /lib instead
of the default /lib64 on 64 bit machines.</para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term><parameter>libc_cv_c_cleanup=yes</parameter></term>
<listitem>
@ -111,8 +121,8 @@ cd build</userinput></screen>
cleanup handling support is configured.</para>
</listitem>
</varlistentry>
-->
<!-- <varlistentry>
<varlistentry>
<term><parameter>libc_cv_ctors_header=yes</parameter></term>
<listitem>
<para>Similarly, we pass libc_cv_ctors_header=yes through to the
@ -147,40 +157,65 @@ cd build</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<caution>
<para>At this point, it is imperative to stop and ensure that the basic
functions (compiling and linking) of the new toolchain are working as
expected. To perform a sanity check, run the following commands:</para>
<variablelist>
<title>The meaning of the <command>make install</command> option:</title>
<varlistentry>
<term><parameter>DESTDIR=$LFS</parameter></term>
<listitem>
<para>The <envar>DESTDIR</envar> make variable is used by almost all
packages to define the location where the package should be
installed. If it is not set, it defaults to the root (<filename
class="directory">/</filename>) directory. Here we specify that
the package be installed in <filename class="directory">$LFS
</filename>, which will become the root after <xref linkend=
"ch-tools-chroot"/>.</para>
</listitem>
</varlistentry>
</variablelist>
<caution>
<para>At this point, it is imperative to stop and ensure that the basic
functions (compiling and linking) of the new toolchain are working as
expected. To perform a sanity check, run the following commands:</para>
<screen><userinput>echo 'int main(){}' &gt; dummy.c
$LFS_TGT-gcc dummy.c
readelf -l a.out | grep ': /tools'</userinput></screen>
readelf -l a.out | grep '/ld-linux'</userinput></screen>
<para>If everything is working correctly, there should be no errors,
and the output of the last command will be of the form:</para>
<para>If everything is working correctly, there should be no errors,
and the output of the last command will be of the form:</para>
<screen><computeroutput>[Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
<screen><computeroutput>[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
<para>Note that for 32-bit machines, the interpreter name will be
<filename>/tools/lib/ld-linux.so.2</filename>.</para>
<para>Note that for 32-bit machines, the interpreter name will be
<filename>/lib/ld-linux.so.2</filename>.</para>
<para>If the output is not shown as above or there was no output at all,
then something is wrong. Investigate and retrace the steps to find out
where the problem is and correct it. This issue must be resolved before
continuing on.</para>
<para>If the output is not shown as above or there was no output at all,
then something is wrong. Investigate and retrace the steps to find out
where the problem is and correct it. This issue must be resolved before
continuing on.</para>
<para>Once all is well, clean up the test files:</para>
<para>Once all is well, clean up the test files:</para>
<screen><userinput>rm -v dummy.c a.out</userinput></screen>
</caution>
</caution>
<note><para>Building Binutils in the section after next will serve as an
additional check that the toolchain has been built properly. If Binutils
fails to build, it is an indication that something has gone wrong with the
previous Binutils, GCC, or Glibc installations.</para></note>
<note><para>Building packages in the next sections will serve as an
additional check that the toolchain has been built properly. If some
package, especially binutils-pass2 or gcc-pass2, fails to build, it is
an indication that something has gone wrong with the
previous Binutils, GCC, or Glibc installations.</para></note>
<para>Now that our cross-toolchain is complete, finalize the installation
of the limits.h header. For doing so, run an utility provided by the GCC
developers:</para>
<screen><userinput>$LFS/tools/libexec/gcc/$LFS_TGT/&gcc-version;/install-tools/mkheaders</userinput></screen>
</sect2>

View File

@ -45,21 +45,17 @@
<para>Prepare Grep for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--bindir=/bin</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Grep test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -45,21 +45,19 @@
<para>Prepare Gzip for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr --host=$LFS_TGT</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Gzip test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<para>Move the excutable to its final expected location:</para>
<screen><userinput remap="install">mv -v $LFS/usr/bin/gzip $LFS/bin</userinput></screen>
</sect2>

View File

@ -19,11 +19,11 @@
is to build a new and host-independent toolchain (compiler, assembler,
linker, libraries, and a few useful utilities). The second step uses this
toolchain to build the other essential tools.</para>
<!--
<para>The files compiled in this chapter will be installed under the
<filename class="directory">$LFS/tools</filename> directory to keep them
<filename class="directory">$LFS</filename> directory to keep them
separate from the files installed in the next chapter and the host
production directories. Since the packages compiled here are temporary,
we do not want them to pollute the soon-to-be LFS system.</para>
-->
</sect1>

View File

@ -5,12 +5,12 @@
%general-entities;
]>
<sect1 id="ch-system-kernfs">
<sect1 id="ch-tools-kernfs">
<?dbhtml filename="kernfs.html"?>
<title>Preparing Virtual Kernel File Systems</title>
<indexterm zone="ch-system-kernfs">
<indexterm zone="ch-tools-kernfs">
<primary sortas="e-/dev/">/dev/*</primary>
</indexterm>

View File

@ -0,0 +1,114 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-tools-libstdcpp-pass2" role="wrap">
<?dbhtml filename="gcc-libstdc++-pass2.html"?>
<sect1info condition="script">
<productname>gcc-libstdc++</productname>
<productnumber>&gcc-version;</productnumber>
<address>&gcc-url;</address>
</sect1info>
<title>Libstdc++ from GCC-&gcc-version;, Pass 2</title>
<indexterm zone="ch-tools-libstdcpp-pass2">
<primary sortas="a-GCC">GCC</primary>
<secondary>tools, libstdc++ pass 2</secondary>
</indexterm>
<sect2 role="package">
<title/>
<para>Again, when building <xref linkend="ch-tools-gcc-pass2"/>, we had to
defer the installation of the C++ standard library, because no suitable
compiler was available to compile it: we could not use the compiler
installed, because this compiler is a native
compiler, and should not be used outside of chroot without being at
risk of polluting the build with some host components.</para>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<!-- TODO -->
<seglistitem>
<seg>&libstdcpp-ch5-sbu;</seg>
<seg>&libstdcpp-ch5-du;</seg>
</seglistitem>
</segmentedlist>
</sect2>
<sect2 role="installation">
<title>Installation of Target Libstdc++</title>
<note>
<para><application>Libstdc++</application> is part of the GCC sources.
You should first unpack the GCC tarball and change to the
<filename>gcc-&gcc-version;</filename> directory.</para>
</note>
<para>Create a link which exists when building Libstdc++ in the gcc
tree:</para>
<screen><userinput remap="pre">ln -s gthr-posix.h libgcc/gthr-default.h</userinput></screen>
<para>Create a separate build directory for Libstdc++ and enter it:</para>
<screen><userinput remap="pre">mkdir -v build
cd build</userinput></screen>
<para>Prepare Libstdc++ for compilation:</para>
<screen><userinput remap="configure">../libstdc++-v3/configure \
CXXFLAGS="-g -O2 -D_GNU_SOURCE" \
--prefix=/usr \
--disable-multilib \
--disable-nls \
--disable-libstdcxx-pch</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<varlistentry>
<term><parameter>CXXFLAGS="-g -O2 -D_GNU_SOURCE"</parameter></term>
<listitem>
<para>Those flags are passed by the top level Makefile when doing
a full build of GCC.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-libstdcxx-pch</parameter></term>
<listitem>
<para>This switch prevents the installation of precompiled
include files, which are not needed at this stage.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Compile libstdc++ by running:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Install the library:</para>
<screen><userinput remap="install">make install</userinput></screen>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-gcc" role="."/></para>
</sect2>
</sect1>

View File

@ -5,8 +5,8 @@
%general-entities;
]>
<sect1 id="ch-tools-libstdcpp" role="wrap">
<?dbhtml filename="gcc-libstdc++.html"?>
<sect1 id="ch-tools-libstdcpp-pass1" role="wrap">
<?dbhtml filename="gcc-libstdc++-pass1.html"?>
<sect1info condition="script">
<productname>gcc-libstdc++</productname>
@ -14,11 +14,11 @@
<address>&gcc-url;</address>
</sect1info>
<title>Libstdc++ from GCC-&gcc-version;</title>
<title>Libstdc++ from GCC-&gcc-version;, Pass 1</title>
<indexterm zone="ch-tools-libstdcpp">
<indexterm zone="ch-tools-libstdcpp-pass1">
<primary sortas="a-GCC">GCC</primary>
<secondary>tools, libstdc++</secondary>
<secondary>tools, libstdc++ pass 1</secondary>
</indexterm>
<sect2 role="package">
@ -28,7 +28,8 @@
to compile C++ code
(part of GCC is written in C++), but we had to defer its installation
when we built <xref linkend="ch-tools-gcc-pass1"/>
because it depends on glibc, which was not yet available in /tools.
because it depends on glibc, which was not yet available in the target
directory.
</para>
<segmentedlist>
@ -61,10 +62,10 @@ cd build</userinput></screen>
<screen><userinput remap="configure">../libstdc++-v3/configure \
--host=$LFS_TGT \
--prefix=/tools \
--build=$(../config.guess) \
--prefix=/usr \
--disable-multilib \
--disable-nls \<!--
- -disable-libstdcxx-threads \-->
--disable-nls \
--disable-libstdcxx-pch \
--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/&gcc-version;</userinput></screen>
@ -78,15 +79,7 @@ cd build</userinput></screen>
instead of the one in <filename>/usr/bin</filename>.</para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term><parameter>- -disable-libstdcxx-threads</parameter></term>
<listitem>
<para>Since gcc-pass1 is built without thread support, the C++
thread library cannot be built either.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><parameter>--disable-libstdcxx-pch</parameter></term>
<listitem>
@ -114,7 +107,7 @@ cd build</userinput></screen>
<para>Install the library:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -24,9 +24,8 @@
<sect2 role="package">
<title/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../chapter06/linux-headers.xml"
xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
<para>The Linux API Headers (in linux-&linux-version;.tar.xz) expose the
kernel's API for use by Glibc.</para>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
@ -60,15 +59,148 @@
location.</para>
<screen><userinput remap="make">make headers
</userinput><userinput remap="install">cp -rv usr/include/* /tools/include</userinput></screen>
find usr/include -name '.*' -delete
rm usr/include/Makefile
</userinput><userinput remap="install">cp -rv usr/include $LFS/usr</userinput></screen>
</sect2>
<sect2 role="content">
<title/>
<sect2 id="contents-linux-headers" role="content">
<title>Contents of Linux API Headers</title>
<para>Details on this package are located in
<xref linkend="contents-linux-headers" role="."/></para>
<segmentedlist>
<segtitle>Installed headers</segtitle>
<segtitle>Installed directories</segtitle>
<seglistitem>
<seg>/usr/include/asm/*.h, /usr/include/asm-generic/*.h,
/usr/include/drm/*.h, /usr/include/linux/*.h, /usr/include/misc/*.h,
/usr/include/mtd/*.h, /usr/include/rdma/*.h, /usr/include/scsi/*.h,
/usr/include/sound/*.h, /usr/include/video/*.h,
and /usr/include/xen/*.h</seg>
<seg>/usr/include/asm, /usr/include/asm-generic, /usr/include/drm,
/usr/include/linux, /usr/include/misc, /usr/include/mtd,
/usr/include/rdma, /usr/include/scsi, /usr/include/sound,
/usr/include/video, and /usr/include/xen</seg>
</seglistitem>
</segmentedlist>
<variablelist>
<bridgehead renderas="sect3">Short Descriptions</bridgehead>
<?dbfo list-presentation="list"?>
<?dbhtml list-presentation="table"?>
<varlistentry id="asm">
<term><filename class="headerfile">/usr/include/asm/*.h</filename></term>
<listitem>
<para>The Linux API ASM Headers</para>
<indexterm zone="ch-tools-linux-headers asm">
<primary sortas="e-/usr/include/asm/*.h">/usr/include/asm/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="asm-generic">
<term><filename class="headerfile">/usr/include/asm-generic/*.h</filename></term>
<listitem>
<para>The Linux API ASM Generic Headers</para>
<indexterm zone="ch-tools-linux-headers asm-generic">
<primary sortas="e-/usr/include/asm-generic/*.h">/usr/include/asm-generic/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="drm">
<term><filename class="headerfile">/usr/include/drm/*.h</filename></term>
<listitem>
<para>The Linux API DRM Headers</para>
<indexterm zone="ch-tools-linux-headers drm">
<primary sortas="e-/usr/include/drm/*.h">/usr/include/drm/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="linux">
<term><filename class="headerfile">/usr/include/linux/*.h</filename></term>
<listitem>
<para>The Linux API Linux Headers</para>
<indexterm zone="ch-tools-linux-headers linux">
<primary sortas="e-/usr/include/linux/*.h">/usr/include/linux/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="misc">
<term><filename class="headerfile">/usr/include/misc/*.h</filename></term>
<listitem>
<para>The Linux API Miscellaneous Headers</para>
<indexterm zone="ch-tools-linux-headers misc">
<primary sortas="e-/usr/include/misc/*.h">/usr/include/misc/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="mtd">
<term><filename class="headerfile">/usr/include/mtd/*.h</filename></term>
<listitem>
<para>The Linux API MTD Headers</para>
<indexterm zone="ch-tools-linux-headers mtd">
<primary sortas="e-/usr/include/mtd/*.h">/usr/include/mtd/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="rdma">
<term><filename class="headerfile">/usr/include/rdma/*.h</filename></term>
<listitem>
<para>The Linux API RDMA Headers</para>
<indexterm zone="ch-tools-linux-headers rdma">
<primary sortas="e-/usr/include/rdma/*.h">/usr/include/rdma/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="scsi">
<term><filename class="headerfile">/usr/include/scsi/*.h</filename></term>
<listitem>
<para>The Linux API SCSI Headers</para>
<indexterm zone="ch-tools-linux-headers scsi">
<primary sortas="e-/usr/include/scsi/*.h">/usr/include/scsi/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="sound">
<term><filename class="headerfile">/usr/include/sound/*.h</filename></term>
<listitem>
<para>The Linux API Sound Headers</para>
<indexterm zone="ch-tools-linux-headers sound">
<primary sortas="e-/usr/include/sound/*.h">/usr/include/sound/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="video">
<term><filename class="headerfile">/usr/include/video/*.h</filename></term>
<listitem>
<para>The Linux API Video Headers</para>
<indexterm zone="ch-tools-linux-headers video">
<primary sortas="e-/usr/include/video/*.h">/usr/include/video/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="xen">
<term><filename class="headerfile">/usr/include/xen/*.h</filename></term>
<listitem>
<para>The Linux API Xen Headers</para>
<indexterm zone="ch-tools-linux-headers xen">
<primary sortas="e-/usr/include/xen/*.h">/usr/include/xen/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
</variablelist>
</sect2>

View File

@ -50,27 +50,22 @@ echo "#define _IO_IN_BACKUP 0x100" >> lib/stdio-impl.h</userinput></screen>
<para>Prepare M4 for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess)</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the M4 test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-m4" role="."/></para>

View File

@ -41,41 +41,20 @@
<sect2 role="installation">
<title>Installation of Make</title>
<!--
<para>First, work around an error caused by glibc-2.27 and later:</para>
<screen><userinput remap="pre">sed -i '211,217 d; 219,229 d; 232 d' glob/glob.c</userinput></screen>
-->
<para>Prepare Make for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools --without-guile</userinput></screen>
<variablelist>
<title>The meaning of the configure option:</title>
<varlistentry>
<term><parameter>--without-guile</parameter></term>
<listitem>
<para>This ensures that Make-&make-version; won't link against Guile libraries, which
may be present on the host system, but won't be available within the
<command>chroot</command> environment in the next chapter.</para>
</listitem>
</varlistentry>
</variablelist>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess)</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Make test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -49,15 +49,20 @@
<para>Prepare Ncurses for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools \
--with-shared \
--without-debug \
--without-ada \
--enable-widec \
--enable-overwrite</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(./config.guess) \
--mandir=/usr/share/man \
--with-shared \
--without-debug \
--without-ada \
--without-normal \
--disable-db-install \
--enable-widec \
--enable-pc-files</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<title>The meaning of the new configure options:</title>
<varlistentry>
<term><parameter>--without-ada</parameter></term>
@ -68,17 +73,6 @@
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--enable-overwrite</parameter></term>
<listitem>
<para>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>
</varlistentry>
<varlistentry>
<term><parameter>--enable-widec</parameter></term>
<listitem>
@ -93,22 +87,53 @@
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--enable-pc-files</parameter></term>
<listitem>
<para>This switch generates and installs .pc files for pkg-config.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--without-normal</parameter></term>
<listitem>
<para>This switch disables building and installing most static libraries.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-db-install</parameter></term>
<listitem>
<para>This switch disables building the terminfo database: it is not
needed at this stage, and if <command>tic</command> is too old,
it cannot compile recent databases.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>This package has a test suite, but it can only be run after the
package has been installed. The tests reside in the
<filename class="directory">test/</filename> directory. See the
<filename>README</filename> file in that directory for further details.
</para>
<para>Install the package:</para>
<!-- TODO: check and document -->
<screen><userinput remap="install">make DESTDIR=$LFS install
ln -s libncursesw.so $LFS/usr/lib/libncurses.so</userinput></screen>
<para>Move the shared libraries to the
<filename class="directory">/lib</filename> directory, where they are
expected to reside:</para>
<screen><userinput remap="install">mv -v $LFS/usr/lib/libncursesw.so.6* $LFS/lib</userinput></screen>
<para>Because the libraries have been moved, one symlink points to
a non-existent file. Recreate it:</para>
<screen><userinput remap="install">ln -sfv ../../lib/$(readlink $LFS/usr/lib/libncursesw.so) $LFS/usr/lib/libncursesw.so</userinput></screen>
<screen><userinput remap="install">make install
ln -s libncursesw.so /tools/lib/libncurses.so</userinput></screen>
</sect2>

View File

@ -45,21 +45,17 @@
<para>Prepare Patch for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess)</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Patch test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -45,11 +45,10 @@
<para>Prepare Perl for compilation:</para>
<screen><userinput remap="configure">sh Configure -des -Dprefix=/tools -Dlibs=-lm -Uloclibpth -Ulocincpth</userinput></screen>
<screen><userinput remap="configure">sh Configure -des -Dprefix=/usr</userinput></screen>
<variablelist>
<title>The meaning of the Configure options:</title>
<title>The meaning of the new Configure options:</title>
<varlistentry>
<term><parameter>-des</parameter></term>
<listitem>
@ -59,36 +58,13 @@
</listitem>
</varlistentry>
<varlistentry>
<term>
<parameter>-Uloclibpth</parameter> and
<parameter>-Ulocincpth</parameter>
</term>
<listitem>
<para>These entries undefine variables that cause the configuration
to search for locally installed components that may exist on the
host system.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Build the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Although Perl comes with a test suite, it would be better to wait
until it is installed in the next chapter.</para>
<para>Only a few of the utilities and libraries need to be installed at this
time:</para>
<screen><userinput remap="install">cp -v perl cpan/podlators/scripts/pod2man /tools/bin
mkdir -pv /tools/lib/perl5/&perl-version;
cp -Rv lib/* /tools/lib/perl5/&perl-version;</userinput></screen>
<screen><userinput remap="install">make install</userinput></screen>
</sect2>

View File

@ -5,8 +5,8 @@
%general-entities;
]>
<sect1 id="ch-tools-Python" role="wrap">
<?dbhtml filename="Python.html"?>
<sect1 id="ch-system-Python-temp" role="wrap">
<?dbhtml filename="Python-temp.html"?>
<sect1info condition="script">
<productname>Python</productname>
@ -16,9 +16,9 @@
<title>Python-&python-version;</title>
<indexterm zone="ch-tools-Python">
<indexterm zone="ch-system-Python-temp">
<primary sortas="a-Python">Python</primary>
<secondary>tools</secondary>
<secondary>temporary</secondary>
</indexterm>
<sect2 role="package">
@ -50,18 +50,9 @@
uppercase first letter).</para>
</note>
<para>This package first builds the Python interpreter, then some
standard Python modules. The main script for building modules is
written in Python, and uses hard-coded paths to the host <filename
class="directory">/usr/include</filename> and <filename
class="directory">/usr/lib</filename> directories. To prevent them
from being used, issue:</para>
<screen><userinput remap="pre">sed -i '/def add_multiarch_paths/a \ return' setup.py</userinput></screen>
<para>Prepare Python for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools --without-ensurepip</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr --without-ensurepip</userinput></screen>
<variablelist>
<title>The meaning of the configure option:</title>
@ -80,10 +71,6 @@
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. The test suite requires TK and
and X Windows and cannot be run at this time.
</para>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>

View File

@ -45,21 +45,17 @@
<para>Prepare Sed for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--bindir=/bin</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Sed test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -15,12 +15,19 @@
The executables and libraries built so far contain about 70 MB of unneeded
debugging symbols. Remove those symbols with:</para>
<screen><userinput>strip --strip-debug /tools/lib/*
/usr/bin/strip --strip-unneeded /tools/{,s}bin/*</userinput></screen>
<screen><userinput>$LFS_TGT-strip --strip-debug $LFS/usr/lib/*
$LFS_TGT-strip --strip-unneeded $LFS/usr/{,s}bin/*</userinput></screen>
<para>These commands will skip a number of files, reporting that it does not
recognize their file format. Most of these are scripts instead of binaries.
Also use the system strip command to include the strip binary in /tools.</para>
Note that we use the <command>strip</command> program built in
<quote>Binutils pass 1</quote>, since it is the one that knows how to strip
our cross-compiled programs.</para>
<!-- Normally, the host "strip" could be used too, since it is actually the
same computer. But Some old versions of binutils may generate buggy crt1.o
and the like, because they do not know about recently introduced symbol
types. For more details,
see https://sourceware.org/bugzilla/show_bug.cgi?id=22875-->
<para>Take care <emphasis>not</emphasis> to use
<parameter>--strip-unneeded</parameter> on the libraries. The static
@ -29,14 +36,14 @@
<para>To save more, remove the documentation:</para>
<screen><userinput>rm -rf /tools/{,share}/{info,man,doc}</userinput></screen>
<screen><userinput>rm -rf $LFS/usr/{,share}/{info,man,doc}</userinput></screen>
<para>The libtool .la files are only useful when linking with static
libraries. They are unneeded, and potentially harmful, when using dynamic
shared libraries, specially when using also non-autotools build systems.
Remove those files now:</para>
<screen><userinput>find /tools/{lib,libexec} -name \*.la -delete</userinput></screen>
<screen><userinput>find $LFS/usr/{lib,libexec} -name \*.la -delete</userinput></screen>
<para>At this point, you should have at least 3 GB of free space in
<envar>$LFS</envar> that can be used to build and install Glibc and Gcc in

View File

@ -45,21 +45,18 @@
<para>Prepare Tar for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess) \
--bindir=/bin</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Tar test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
</sect2>

View File

@ -3,6 +3,8 @@
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
<!ENTITY tdbc-ver "1.1.1">
<!ENTITY itcl-ver "4.2.0">
]>
<sect1 id="ch-tools-tcl" role="wrap">
@ -46,8 +48,7 @@
installed to support running the test suites for GCC and Binutils and other
packages. Installing three packages for testing purposes may seem
excessive, but it is very reassuring, if not essential, to know that the
most important tools are working properly. Even if the test suites are not
run in this chapter (they are not mandatory), these packages are required
most important tools are working properly. These packages are required
to run the test suites in <xref linkend="chapter-building-system"/>.</para>
<para>Note that the Tcl package used here is a minimal version needed
@ -56,27 +57,54 @@
<para>Prepare Tcl for compilation:</para>
<screen><userinput remap="configure">cd unix
./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">SRCDIR=$(pwd)
cd unix
./configure --prefix=/usr \
--mandir=/usr/share/man \
$([ "$(uname -m)" = x86_64 ] &amp;&amp; echo --enable-64bit)</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<varlistentry>
<term><parameter>$([ "$(uname -m)" = x86_64 ] &amp;&amp; echo --enable-64bit)</parameter></term>
<listitem>
<para>The construct <parameter>$(&lt;shell command&gt;)</parameter>
is replaced by the output of the chell command. Here this output is
empty if running on a 32 bit machine, and is
<parameter>--enable-64bit</parameter> if running on a 64 bit machine.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>Build the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<screen><userinput remap="make">make
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Tcl test suite anyway, issue the following command:</para>
sed -e "s|$SRCDIR/unix|/usr/lib|" \
-e "s|$SRCDIR|/usr/include|" \
-i tclConfig.sh
<screen><userinput remap="test">TZ=UTC make test</userinput></screen>
sed -e "s|$SRCDIR/unix/pkgs/tdbc&tdbc-ver;|/usr/lib/tdbc&tdbc-ver;|" \
-e "s|$SRCDIR/pkgs/tdbc&tdbc-ver;/generic|/usr/include|" \
-e "s|$SRCDIR/pkgs/tdbc&tdbc-ver;/library|/usr/lib/tcl8.6|" \
-e "s|$SRCDIR/pkgs/tdbc&tdbc-ver;|/usr/include|" \
-i pkgs/tdbc&tdbc-ver;/tdbcConfig.sh
<para>The Tcl test suite may experience failures under certain host
conditions that are not fully understood. Therefore, test suite failures
here are not surprising, and are not considered critical. The
<parameter>TZ=UTC</parameter> parameter sets the time zone to Coordinated
Universal Time (UTC), but only
for the duration of the test suite run. This ensures that the clock tests
are exercised correctly. Details on the <envar>TZ</envar> environment
variable are provided in <xref linkend="chapter-config"/>.</para>
sed -e "s|$SRCDIR/unix/pkgs/itcl&itcl-ver;|/usr/lib/itcl&itcl-ver;|" \
-e "s|$SRCDIR/pkgs/itcl&itcl-ver;/generic|/usr/include|" \
-e "s|$SRCDIR/pkgs/itcl&itcl-ver;|/usr/include|" \
-i pkgs/itcl&itcl-ver;/itclConfig.sh
unset SRCDIR</userinput></screen>
<para>The various <quote>sed</quote> after the <quote>make</quote> command
remove references to the build directory from various configuration files,
and replaces them with the install directory. This is not mandatory
for the remaining of LFS, but may be needed in case a package built later
uses Tcl.</para>
<para>Install the package:</para>
@ -85,7 +113,7 @@
<para>Make the installed library writable so debugging symbols can
be removed later:</para>
<screen><userinput remap="install">chmod -v u+w /tools/lib/libtcl&tcl-major-version;.so</userinput></screen>
<screen><userinput remap="install">chmod -v u+w /usr/lib/libtcl&tcl-major-version;.so</userinput></screen>
<para>Install Tcl's headers. The next package, Expect, requires them
to build.</para>
@ -94,7 +122,7 @@
<para>Now make a necessary symbolic link:</para>
<screen><userinput remap="install">ln -sv tclsh&tcl-major-version; /tools/bin/tclsh</userinput></screen>
<screen><userinput remap="install">ln -sfv tclsh&tcl-major-version; /usr/bin/tclsh</userinput></screen>
</sect2>

View File

@ -5,8 +5,8 @@
%general-entities;
]>
<sect1 id="ch-tools-texinfo" role="wrap">
<?dbhtml filename="texinfo.html"?>
<sect1 id="ch-system-texinfo-temp" role="wrap">
<?dbhtml filename="texinfo-temp.html"?>
<sect1info condition="script">
<productname>texinfo</productname>
@ -16,9 +16,9 @@
<title>Texinfo-&texinfo-version;</title>
<indexterm zone="ch-tools-texinfo">
<indexterm zone="ch-system-texinfo-temp">
<primary sortas="a-Texinfo">Texinfo</primary>
<secondary>tools</secondary>
<secondary>temporary</secondary>
</indexterm>
<sect2 role="package">
@ -45,7 +45,7 @@
<para>Prepare Texinfo for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr</userinput></screen>
<note>
<para>As part of the configure process, a test is made that indicates an
@ -57,12 +57,6 @@
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Texinfo test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>

View File

@ -24,143 +24,312 @@
process has been designed to minimize the risks for new readers and to provide
the most educational value at the same time.</para>
<note>
<para>Before continuing, be aware of the name of the working platform,
often referred to as the target triplet. A simple way to determine the
name of the target triplet is to run the <command>config.guess</command>
script that comes with the source for many packages. Unpack the Binutils
sources and run the script: <userinput>./config.guess</userinput> and note
the output. For example, for a 32-bit Intel processor the
output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>.</para>
<para>The build process is based on the process of
<emphasis>cross-compilation</emphasis>. Cross-compilation is normally used
for building a compiler and its toolchain for a machine different from
the one that is used for the build. This is not strictly needed for LFS,
since the machine where the new system will run is the same as the one
used for the build. But cross-compilation has the great advantage that
anything that is cross-compiled cannot depend on the host environment.</para>
<para>Also be aware of the name of the platform's dynamic linker, often
referred to as the dynamic loader (not to be confused with the standard
linker <command>ld</command> that is part of Binutils). The dynamic linker
provided by Glibc finds and loads the shared libraries needed by a program,
prepares the program to run, and then runs it. The name of the dynamic
linker for a 32-bit Intel machine will be <filename
class="libraryfile">ld-linux.so.2</filename> (<filename
class="libraryfile">ld-linux-x86-64.so.2</filename> for 64-bit systems). A
sure-fire way to determine the name of the dynamic linker is to inspect a
random binary from the host system by running: <userinput>readelf -l
&lt;name of binary&gt; | grep interpreter</userinput> and noting the
output. The authoritative reference covering all platforms is in the
<filename>shlib-versions</filename> file in the root of the Glibc source
tree.</para>
</note>
<sect2 id="cross-compile" xreflabel="About Cross-Compilation">
<para>Some key technical points of how the <xref
linkend="chapter-temporary-tools"/> build method works:</para>
<title>About Cross-Compilation</title>
<itemizedlist>
<listitem>
<para>Slightly adjusting the name of the working platform, by changing the
&quot;vendor&quot; field target triplet by way of the
<envar>LFS_TGT</envar> variable, ensures that the first build of Binutils
and GCC produces a compatible cross-linker and cross-compiler. Instead of
producing binaries for another architecture, the cross-linker and
cross-compiler will produce binaries compatible with the current
hardware.</para>
</listitem>
<listitem>
<para> The temporary libraries are cross-compiled. Because a
cross-compiler by its nature cannot rely on anything from its host
system, this method removes potential contamination of the target
system by lessening the chance of headers or libraries from the host
being incorporated into the new tools. Cross-compilation also allows for
the possibility of building both 32-bit and 64-bit libraries on 64-bit
capable hardware.</para>
</listitem>
<listitem>
<para>Careful manipulation of the GCC source tells the compiler which target
dynamic linker will be used.</para>
</listitem>
</itemizedlist>
<para>Cross-compilation involves some concepts that deserve a section on
their own. Although this section may be omitted in a first reading, it
is strongly suggested to come back to it later in order to get a full
grasp of the build process.</para>
<para>Binutils is installed first because the <command>configure</command>
runs of both GCC and Glibc perform various feature tests on the assembler
and linker to determine which software features to enable or disable. This
is more important than one might first realize. An incorrectly configured
GCC or Glibc can result in a subtly broken toolchain, where the impact of
such breakage might not show up until near the end of the build of an
entire distribution. A test suite failure will usually highlight this error
before too much additional work is performed.</para>
<para>Let us first define some terms used in this context:</para>
<para>Binutils installs its assembler and linker in two locations,
<filename class="directory">/tools/bin</filename> and <filename
class="directory">/tools/$LFS_TGT/bin</filename>. The tools in one
location are hard linked to the other. An important facet of the linker is
its library search order. Detailed information can be obtained from
<command>ld</command> by passing it the <parameter>--verbose</parameter>
flag. For example, an <userinput>ld --verbose | grep SEARCH</userinput>
will illustrate the current search paths and their order. It shows which
files are linked by <command>ld</command> by compiling a dummy program and
passing the <parameter>--verbose</parameter> switch to the linker. For example,
<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
will show all the files successfully opened during the linking.</para>
<variablelist>
<varlistentry><term>build</term><listitem>
<para>is the machine where we build programs. Note that this machine
is referred to as the <quote>host</quote> in other
sections.</para></listitem>
</varlistentry>
<para>The next package installed is GCC. An example of what can be
seen during its run of <command>configure</command> is:</para>
<varlistentry><term>host</term><listitem>
<para>is the machine/system where the built programs will run. Note
that this use of <quote>host</quote> is not the same as in other
sections.</para></listitem>
</varlistentry>
<screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
<varlistentry><term>target</term><listitem>
<para>is only used for compilers. It is the machine the compiler
produces code for. It may be different from both build and
host.</para></listitem>
</varlistentry>
<para>This is important for the reasons mentioned above. It also demonstrates
that GCC's configure script does not search the PATH directories to find which
tools to use. However, during the actual operation of <command>gcc</command>
itself, the same search paths are not necessarily used. To find out which
standard linker <command>gcc</command> will use, run:
<userinput>gcc -print-prog-name=ld</userinput>.</para>
</variablelist>
<para>Detailed information can be obtained from <command>gcc</command> by
passing it the <parameter>-v</parameter> command line option while compiling
a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
detailed information about the preprocessor, compilation, and assembly stages,
including <command>gcc</command>'s included search paths and their order.</para>
<para>As an example, let us imagine the following scenario: we may have a
compiler on a slow machine only, let's call the machine A, and the compiler
ccA. We may have also a fast machine (B), but with no compiler, and we may
want to produce code for a another slow machine (C). Then, to build a
compiler for machine C, we would have three stages:</para>
<para>Next installed are sanitized Linux API headers. These allow the standard
C library (Glibc) to interface with features that the Linux kernel will
provide.</para>
<informaltable align="center">
<tgroup cols="5">
<colspec colnum="1" align="center"/>
<colspec colnum="2" align="center"/>
<colspec colnum="3" align="center"/>
<colspec colnum="4" align="center"/>
<colspec colnum="5" align="left"/>
<thead>
<row><entry>Stage</entry><entry>Build</entry><entry>Host</entry>
<entry>Target</entry><entry>Action</entry></row>
</thead>
<tbody>
<row>
<entry>1</entry><entry>A</entry><entry>A</entry><entry>B</entry>
<entry>build cross-compiler cc1 using ccA on machine A</entry>
</row>
<row>
<entry>2</entry><entry>A</entry><entry>B</entry><entry>B</entry>
<entry>build cross-compiler cc2 using cc1 on machine A</entry>
</row>
<row>
<entry>3</entry><entry>B</entry><entry>C</entry><entry>C</entry>
<entry>build compiler ccC using cc2 on machine B</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>The next package installed is Glibc. The most important considerations
for building Glibc are the compiler, binary tools, and kernel headers. The
compiler is generally not an issue since Glibc will always use the compiler
relating to the <parameter>--host</parameter> parameter passed to its
configure script; e.g. in our case, the compiler will be
<command>i686-lfs-linux-gnu-gcc</command>. The binary tools and kernel
headers can be a bit more complicated. Therefore, take no risks and use the
available configure switches to enforce the correct selections. After the run
of <command>configure</command>, check the contents of the
<filename>config.make</filename> file in the <filename
class="directory">glibc-build</filename> directory for all important details.
Note the use of <parameter>CC="i686-lfs-gnu-gcc"</parameter> to control which
binary tools are used and the use of the <parameter>-nostdinc</parameter> and
<parameter>-isystem</parameter> flags to control the compiler's include
search path. These items highlight an important aspect of the Glibc
package&mdash;it is very self-sufficient in terms of its build machinery and
generally does not rely on toolchain defaults.</para>
<para>Then, all the other programs needed by machine C can be compiled
using cc2 on the fast machine B. Note that unless B can run programs
produced for C, there is no way to test the built programs until machine
C itself is running. For example, for testing ccC, we may want to add a
fourth stage:</para>
<para>During the second pass of Binutils, we are able to utilize the
<parameter>--with-lib-path</parameter> configure switch to control
<command>ld</command>'s library search path.</para>
<informaltable align="center">
<tgroup cols="5">
<colspec colnum="1" align="center"/>
<colspec colnum="2" align="center"/>
<colspec colnum="3" align="center"/>
<colspec colnum="4" align="center"/>
<colspec colnum="5" align="left"/>
<thead>
<row><entry>Stage</entry><entry>Build</entry><entry>Host</entry>
<entry>Target</entry><entry>Action</entry></row>
</thead>
<tbody>
<row>
<entry>4</entry><entry>C</entry><entry>C</entry><entry>C</entry>
<entry>rebuild and test ccC using itself on machine C</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>For the second pass of GCC, its sources also need to be modified to
tell GCC to use the new dynamic linker. Failure to do so will result in the
GCC programs themselves having the name of the dynamic linker from the host
system's <filename class="directory">/lib</filename> directory embedded into
them, which would defeat the goal of getting away from the host. From this
point onwards, the core toolchain is self-contained and self-hosted. The
remainder of the <xref linkend="chapter-temporary-tools"/> packages all build
against the new Glibc in <filename
class="directory">/tools</filename>.</para>
<para>In the example above, only cc1 and cc2 are cross-compilers, that is,
they produce code for a machine different from the one they are run on.
The other compilers ccA and ccC produce code for the machine they are run
on. Such compilers are called <emphasis>native</emphasis> compilers.</para>
<para>Upon entering the chroot environment in <xref
linkend="chapter-building-system"/>, the first major package to be
installed is Glibc, due to its self-sufficient nature mentioned above.
Once this Glibc is installed into <filename
class="directory">/usr</filename>, we will perform a quick changeover of the
toolchain defaults, and then proceed in building the rest of the target
LFS system.</para>
</sect2>
<sect2 id="lfs-cross">
<title>Implementation of Cross-Compilation for LFS</title>
<note>
<para>Almost all the build systems use names of the form
cpu-vendor-kernel-os referred to as the machine triplet. An astute
reader may wonder why a <quote>triplet</quote> refers to a four component
name. The reason is history: initially, three component names were enough
to designate unambiguously a machine, but with new machines and systems
appearing, that proved insufficient. The word <quote>triplet</quote>
remained. A simple way to determine your machine triplet is to run
the <command>config.guess</command>
script that comes with the source for many packages. Unpack the Binutils
sources and run the script: <userinput>./config.guess</userinput> and note
the output. For example, for a 32-bit Intel processor the
output will be <emphasis>i686-pc-linux-gnu</emphasis>. On a 64-bit
system it will be <emphasis>x86_64-pc-linux-gnu</emphasis>.</para>
<para>Also be aware of the name of the platform's dynamic linker, often
referred to as the dynamic loader (not to be confused with the standard
linker <command>ld</command> that is part of Binutils). The dynamic linker
provided by Glibc finds and loads the shared libraries needed by a
program, prepares the program to run, and then runs it. The name of the
dynamic linker for a 32-bit Intel machine will be <filename
class="libraryfile">ld-linux.so.2</filename> (<filename
class="libraryfile">ld-linux-x86-64.so.2</filename> for 64-bit systems). A
sure-fire way to determine the name of the dynamic linker is to inspect a
random binary from the host system by running: <userinput>readelf -l
&lt;name of binary&gt; | grep interpreter</userinput> and noting the
output. The authoritative reference covering all platforms is in the
<filename>shlib-versions</filename> file in the root of the Glibc source
tree.</para>
</note>
<para>In order to fake a cross compilation, the name of the host triplet
is slightly adjusted by changing the &quot;vendor&quot; field in the
<envar>LFS_TGT</envar> variable. We also use the
<parameter>--with-sysroot</parameter> when building the cross linker and
cross compiler, to tell them where to find the needed host files. This
ensures none of the other programs built in <xref
linkend="chapter-temporary-tools"/> can link to libraries on the build
machine. Only two stages are mandatory, and one more for tests:</para>
<informaltable align="center">
<tgroup cols="5">
<colspec colnum="1" align="center"/>
<colspec colnum="2" align="center"/>
<colspec colnum="3" align="center"/>
<colspec colnum="4" align="center"/>
<colspec colnum="5" align="left"/>
<thead>
<row><entry>Stage</entry><entry>Build</entry><entry>Host</entry>
<entry>Target</entry><entry>Action</entry></row>
</thead>
<tbody>
<row>
<entry>1</entry><entry>pc</entry><entry>pc</entry><entry>lfs</entry>
<entry>build cross-compiler cc1 using cc-pc on pc</entry>
</row>
<row>
<entry>2</entry><entry>pc</entry><entry>lfs</entry><entry>lfs</entry>
<entry>build compiler cc-lfs using cc1 on pc</entry>
</row>
<row>
<entry>3</entry><entry>lfs</entry><entry>lfs</entry><entry>lfs</entry>
<entry>rebuild and test cc-lfs using itself on lfs</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>In the above table, <quote>on pc</quote> means the commands are run
on a machine using the already installed distribution. <quote>On
lfs</quote> means the commands are run in a chrooted environment.</para>
<para>Now, there is more about cross-compiling: the C language is not
just a compiler, but also defines a standard library. In this book, the
GNU C library, named glibc, is used. This library must
be compiled for the lfs machine, that is, using the cross compiler cc1.
But the compiler itself uses an internal library implementing complex
instructions not available in the assembler instruction set. This
internal library is named libgcc, and must be linked to the glibc
library to be fully functional! Furthermore, the standard library for
C++ (libstdc++) also needs being linked to glibc. The solution
to this chicken and egg problem is to first build a degraded cc1+libgcc,
lacking some fuctionalities such as threads and exception handling, then
build glibc using this degraded compiler (glibc itself is not
degraded), then build libstdc++. But this last library will lack the
same functionalities as libgcc.</para>
<para>This is not the end of the story: the conclusion of the preceding
paragraph is that cc1 is unable to build a fully functional libstdc++, but
this is the only compiler available for building the C/C++ libraries
during stage 2! Of course, the compiler built during stage 2, cc-lfs,
would be able to build those libraries, but (i) the build system of
gcc does not know that it is usable on pc, and (ii) using it on pc
would be at risk of linking to the pc libraries, since cc-lfs is a native
compiler. So we have to build libstdc++ later, in chroot.</para>
</sect2>
<sect2 id="other-details">
<title>Other procedural details</title>
<para>The cross-compiler will be installed in a separate <filename
class="directory">$LFS/tools</filename> directory, since it will not
be part of the final system.</para>
<para>Binutils is installed first because the <command>configure</command>
runs of both GCC and Glibc perform various feature tests on the assembler
and linker to determine which software features to enable or disable. This
is more important than one might first realize. An incorrectly configured
GCC or Glibc can result in a subtly broken toolchain, where the impact of
such breakage might not show up until near the end of the build of an
entire distribution. A test suite failure will usually highlight this error
before too much additional work is performed.</para>
<para>Binutils installs its assembler and linker in two locations,
<filename class="directory">$LFS/tools/bin</filename> and <filename
class="directory">$LFS/tools/$LFS_TGT/bin</filename>. The tools in one
location are hard linked to the other. An important facet of the linker is
its library search order. Detailed information can be obtained from
<command>ld</command> by passing it the <parameter>--verbose</parameter>
flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command>
will illustrate the current search paths and their order. It shows which
files are linked by <command>ld</command> by compiling a dummy program and
passing the <parameter>--verbose</parameter> switch to the linker. For
example,
<command>$LFS_TGT-gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</command>
will show all the files successfully opened during the linking.</para>
<para>The next package installed is GCC. An example of what can be
seen during its run of <command>configure</command> is:</para>
<screen><computeroutput>checking what assembler to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /mnt/lfs/tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
<para>This is important for the reasons mentioned above. It also
demonstrates that GCC's configure script does not search the PATH
directories to find which tools to use. However, during the actual
operation of <command>gcc</command> itself, the same search paths are not
necessarily used. To find out which standard linker <command>gcc</command>
will use, run: <command>$LFS_TGT-gcc -print-prog-name=ld</command>.</para>
<para>Detailed information can be obtained from <command>gcc</command> by
passing it the <parameter>-v</parameter> command line option while compiling
a dummy program. For example, <command>gcc -v dummy.c</command> will show
detailed information about the preprocessor, compilation, and assembly
stages, including <command>gcc</command>'s included search paths and their
order.</para>
<para>Next installed are sanitized Linux API headers. These allow the
standard C library (Glibc) to interface with features that the Linux
kernel will provide.</para>
<para>The next package installed is Glibc. The most important
considerations for building Glibc are the compiler, binary tools, and
kernel headers. The compiler is generally not an issue since Glibc will
always use the compiler relating to the <parameter>--host</parameter>
parameter passed to its configure script; e.g. in our case, the compiler
will be <command>$LFS_TGT-gcc</command>. The binary tools and kernel
headers can be a bit more complicated. Therefore, take no risks and use
the available configure switches to enforce the correct selections. After
the run of <command>configure</command>, check the contents of the
<filename>config.make</filename> file in the <filename
class="directory">build</filename> directory for all important details.
Note the use of <parameter>CC="$LFS_TGT-gcc"</parameter> (with
<envar>$LFS_TGT</envar> expanded) to control which binary tools are used
and the use of the <parameter>-nostdinc</parameter> and
<parameter>-isystem</parameter> flags to control the compiler's include
search path. These items highlight an important aspect of the Glibc
package&mdash;it is very self-sufficient in terms of its build machinery
and generally does not rely on toolchain defaults.</para>
<para>As said above, the standard C++ library is compiled next, followed
by all the programs that need themselves to be built. The install step
uses the <envar>DESTDIR</envar> variable to have the programs land into
the LFS filesystem.</para>
<para>Then the native lfs compiler is built. First Binutils Pass 2, with
the same <envar>DESTDIR</envar> install as the other programs, then the
second pass of GCC, omitting libstdc++ and other non-important libraries.
Due to some weird logic in GCC's configure script,
<envar>CC_FOR_TARGET</envar> ends up as <command>cc</command> when host
is the same as target, but is different from build. This is why
<parameter>CC_FOR_TARGET=$LFS_TGT-gcc</parameter> is put explicitely into
the configure options.</para>
<para>Upon entering the chroot environment in <xref
linkend="chapter-building-system"/>, the first task is to install
libstdc++. Then temporary installations of programs needed for the proper
operation of the toolchain are performed. Programs needed for testing
other programs are also built. From this point onwards, the
core toolchain is self-contained and self-hosted. In the remainder of
the <xref linkend="chapter-building-system"/>, final versions of all the
packages needed for a fully functional system are built, tested and
installed.</para>
</sect2>
</sect1>

View File

@ -41,66 +41,55 @@
<sect2 role="installation">
<title>Installation of Util-linux</title>
<para>First create a directory
to enable storage for the <command>hwclock</command> program:</para>
<screen><userinput remap="pre">mkdir -pv /var/lib/hwclock</userinput></screen>
<para>Prepare Util-linux for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools \
--without-python \
--disable-makeinstall-chown \
--without-systemdsystemunitdir \
--without-ncurses \
PKG_CONFIG=""</userinput></screen>
<screen><userinput remap="configure">./configure ADJTIME_PATH=/var/lib/hwclock/adjtime \
--docdir=/usr/share/doc/util-linux-&util-linux-version; \
--disable-chfn-chsh \
--disable-login \
--disable-nologin \
--disable-su \
--disable-setpriv \
--disable-runuser \
--disable-pylibmount \
--disable-static \
--without-python</userinput></screen>
<variablelist>
<title>The meaning of the configure option:</title>
<title>The meaning of the configure options:</title>
<!-- TODO -->
<varlistentry>
<term><parameter>ADJTIME_PATH=/var/lib/hwclock/adjtime</parameter></term>
<listitem>
<para>This sets the location of the file recording information about
the hardware clock, in accordance to the FHS. This is not stricly
needed fot his temporary tool, but it prevent creating a file
at another location, which would not be overwritten or removed
when building the final util-linux.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-*</parameter></term>
<listitem>
<para>Those switches prevent warnings about building components
that require packages not in LFS or not installed yet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--without-python</parameter></term>
<listitem>
<para>This switch disables using <application>Python</application>
if it is installed on the host system. It avoids trying to build
unneeded bindings.</para>
<para>This switch disables using <application>Python</application>.
It avoids trying to build unneeded bindings.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--disable-makeinstall-chown</parameter></term>
<listitem>
<para>This switch disables using the <command>chown</command> command
during installation. This is not needed when installing into the
/tools directory and avoids the necessity of installing as
root.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--without-ncurses</parameter></term>
<listitem>
<para>This switch disables using the ncurses library for
the build process. This is not needed when installing into the
/tools directory and avoids problems on some host distros.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>--without-systemdsystemunitdir</parameter></term>
<listitem>
<para>On systems that use systemd, the package tries to install
a systemd specific file to a non-existent directory in /tools.
This switch disables the unnecessary action.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><envar>PKG_CONFIG=""</envar></term>
<listitem>
<para>Setting this environment variable prevents adding unneeded
features that may be available on the host. Note that the location
shown for setting this environment variable is different from other
LFS sections where variables are set preceding the command. This
location is shown to demonstrate an alternative way of setting an
environment variable when using configure.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Compile the package:</para>

View File

@ -45,29 +45,32 @@
<para>Prepare Xz for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/tools</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr \
--host=$LFS_TGT \
--build=$(build-aux/config.guess) \
--disable-static \
--docdir=/usr/share/doc/xz-&xz-version;</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<para>Compilation is now complete. As discussed earlier, running the test
suite is not mandatory for the temporary tools here in this chapter. To run
the Xz test suite anyway, issue the following command:</para>
<screen><userinput remap="test">make check</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>
<screen><userinput remap="install">make DESTDIR=$LFS install</userinput></screen>
<para>Make sure that all essential files are in the correct directory:</para>
<screen><userinput remap="install">mv -v $LFS/usr/bin/{lzma,unlzma,lzcat,xz,unxz,xzcat} $LFS/bin
mv -v $LFS/usr/lib/liblzma.so.* $LFS/lib
ln -svf ../../lib/$(readlink $LFS/usr/lib/liblzma.so) $LFS/usr/lib/liblzma.so</userinput></screen>
</sect2>
<sect2 role="content">
<title/>
<para>Details on this package are located in
<xref linkend="contents-xz" role="."/></para>
<para>Details on this package are located in<!-- TODO
<xref linkend="contents-xz" role="."/> --></para>
</sect2>

View File

@ -50,7 +50,8 @@
--libexecdir=/usr/lib \
--docdir=/usr/share/doc/acl-&acl-version;</userinput></screen>
<screen revision="systemd"><userinput remap="configure">./configure --prefix=/usr \
<screen revision="systemd"><userinput remap="configure">
./configure --prefix=/usr \
--disable-static \
--libexecdir=/usr/lib \
--docdir=/usr/share/doc/acl-&acl-version;</userinput></screen>

View File

@ -43,13 +43,15 @@
<para>Prepare Attr for compilation:</para>
<screen revision="sysv"><userinput remap="configure">./configure --prefix=/usr \
<screen revision="sysv"><userinput remap="configure">
./configure --prefix=/usr \
--bindir=/bin \
--disable-static \
--sysconfdir=/etc \
--docdir=/usr/share/doc/attr-&attr-version;</userinput></screen>
<screen revision="systemd"><userinput remap="configure">./configure --prefix=/usr \
<screen revision="systemd"><userinput remap="configure">
./configure --prefix=/usr \
--disable-static \
--sysconfdir=/etc \
--docdir=/usr/share/doc/attr-&attr-version;</userinput></screen>

View File

@ -40,62 +40,18 @@
<sect2 role="installation">
<title>Installation of Bc</title>
<!--
<para>First, change an internal script to use <command>sed</command> instead
of <command>ed</command>:</para>
<screen><userinput remap="pre">cat &gt; bc/fix-libmath_h &lt;&lt; "EOF"
#! /bin/bash
sed -e '1 s/^/{"/' \
-e 's/$/",/' \
-e '2,$ s/^/"/' \
-e '$ d' \
-i libmath.h
sed -e '$ s/$/0}/' \
-i libmath.h
EOF</userinput></screen>
<para>Create temporary symbolic links so the package can find
the readline library and confirm that its required libncurses
library is available. Even though the libraries are in /tools/lib
at this point, the system will use /usr/lib at the end of
this chapter.</para>
<screen><userinput remap="pre">ln -sv /tools/lib/libncursesw.so.6 /usr/lib/libncursesw.so.6
ln -sfv libncursesw.so.6 /usr/lib/libncurses.so</userinput></screen>
<para>Fix an issue in <command>configure</command> due to missing
files in the early stages of LFS:</para>
<screen><userinput remap="pre">sed -i -e '/flex/s/as_fn_error/: ;; # &amp;/' configure</userinput></screen>
-->
<para>Prepare Bc for compilation:</para>
<!--
<screen><userinput remap="configure">./configure - -prefix=/usr \
- -with-readline \
- -mandir=/usr/share/man \
- -infodir=/usr/share/info</userinput></screen>
-->
<screen><userinput remap="configure">PREFIX=/usr CC=gcc CFLAGS="-std=c99" ./configure.sh -G -O3</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<!--
<varlistentry>
<term><parameter>- -with-readline</parameter></term>
<listitem>
<para>This option tells Bc to use the <filename
class="libraryfile">readline</filename> library that is already
installed on the system rather than using its own readline
version.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><parameter>CC=gcc CFLAGS="-std=c99"</parameter></term>
<listitem>
<para>These parameters specify the compiler and C standard to use.</para>
<para>These parameters specify the compiler and the C standard to use.</para>
</listitem>
</varlistentry>
@ -118,14 +74,6 @@ ln -sfv libncursesw.so.6 /usr/lib/libncurses.so</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<!--
<para>To test bc, run the commands below. There is quite a bit of output,
so you may want to redirect it to a file. There are a very small percentage
of tests (10 of 12,144) that will indicate a round off error at the last
digit.</para>
<screen><userinput remap="test">echo "quit" | ./bc/bc -l Test/checklib.b</userinput></screen>
-->
<para>To test bc, run:</para>

View File

@ -90,10 +90,7 @@ make clean</userinput></screen>
<screen><userinput remap="install">cp -v bzip2-shared /bin/bzip2
cp -av libbz2.so* /lib
ln -sv ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so
rm -v /usr/bin/{bunzip2,bzcat,bzip2}
ln -sv bzip2 /bin/bunzip2
ln -sv bzip2 /bin/bzcat</userinput></screen>
rm -v /usr/bin/{bunzip2,bzcat,bzip2}</userinput></screen>
</sect2>

View File

@ -12,15 +12,11 @@
<title>Installing Basic System Software</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="introduction.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="kernfs.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="pkgmgt.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="chroot.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="creatingdirs.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="createfiles.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="linux-headers.xml"/>
<!-- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="linux-headers.xml"/>-->
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="man-pages.xml"/>
<!-- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="adjusting.xml"/>-->
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="glibc.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="adjusting.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="zlib.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="bzip2.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="xz.xml"/>

View File

@ -56,11 +56,9 @@
<para>Note that the Check test suite may take a relatively long
(up to 4 SBU) time.</para>
<para>Install the package and fix a script:</para>
<para>Install the package:</para>
<screen><userinput remap="install">make docdir=/usr/share/doc/check-&check-version; install &amp;&amp;
sed -i '1 s/tools/usr/' /usr/bin/checkmk</userinput></screen>
<!-- Removes a hardcoded call to /tools/bin/gawk at line 1 of checkmk. -->
<screen><userinput remap="install">make docdir=/usr/share/doc/check-&check-version; install</userinput></screen>
</sect2>

View File

@ -123,8 +123,7 @@ FORCE_UNSAFE_CONFIGURE=1 ./configure \
<screen><userinput remap="test">chown -Rv nobody . </userinput></screen>
<para>Now run the tests. Make sure the PATH in the <userinput>su</userinput>
environment includes /tools/bin.</para>
<para>Now run the tests:</para>
<screen><userinput remap="test">su nobody -s /bin/bash \
-c "PATH=$PATH make RUN_EXPENSIVE_TESTS=yes check"</userinput></screen>

View File

@ -52,11 +52,6 @@ cd build</userinput></screen>
<para>Prepare E2fsprogs for compilation:</para>
<!--<screen><userinput remap="configure">LIBS=-L/tools/lib \
CFLAGS=-I/tools/include \
CFLAGS=-I/tools/include \
PKG_CONFIG_PATH=/tools/lib/pkgconfig \
../configure - -prefix=/usr \-->
<screen><userinput remap="configure">../configure --prefix=/usr \
--bindir=/bin \
--with-root-prefix="" \
@ -68,15 +63,7 @@ PKG_CONFIG_PATH=/tools/lib/pkgconfig \
<variablelist>
<title>The meaning of the environment variable and configure options:</title>
<!--
<varlistentry>
<term><parameter>PKG_CONFIG_PATH, LIBS, CFLAGS</parameter></term>
<listitem>
<para>These variables enable e2fsprogs to be built using the
<xref linkend="ch-tools-util-linux"/> package built earlier.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><parameter>--with-root-prefix=""</parameter> and
<parameter>--bindir=/bin</parameter></term>
@ -117,17 +104,10 @@ PKG_CONFIG_PATH=/tools/lib/pkgconfig \
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>
<!--
<para>To set up and run the test suite we need to first link some
libraries from /tools/lib to a location where the test programs look.
To run the tests, issue:</para>
-->
<para>To run the tests, issue:</para>
<screen><userinput remap="test">make check</userinput></screen>
<!--ln -sfv /tools/lib/lib{blk,uu}id.so.1 lib -->
<!--make LD_LIBRARY_PATH=/tools/lib check</userinput></screen>-->
<para>One of the E2fsprogs tests will attempt to allocate 256 MB of memory.
If you do not have significantly more RAM than this, be sure to enable

View File

@ -50,7 +50,7 @@
This is not present, so we use an environment variable to skip this process.
Now, prepare Flex for compilation:</para>
<screen><userinput remap="configure">HELP2MAN=/tools/bin/true \
<screen><userinput remap="configure">HELP2MAN=/bin/true \
./configure --prefix=/usr --docdir=/usr/share/doc/flex-&flex-version;</userinput></screen>
<para>Compile the package:</para>

View File

@ -58,8 +58,8 @@ cd build</userinput></screen>
<para>Prepare GCC for compilation:</para>
<screen><userinput remap="configure">SED=sed \
../configure --prefix=/usr \
<screen><userinput remap="configure">../configure --prefix=/usr \
LD=ld \
--enable-languages=c,c++ \
--disable-multilib \
--disable-bootstrap \
@ -71,25 +71,8 @@ cd build</userinput></screen>
for instructions on how to build all of GCC's supported languages.</para>
<variablelist>
<title>The meaning of the new configure parameters:</title>
<title>The meaning of the new configure parameter:</title>
<varlistentry>
<term><envar>SED=sed</envar></term>
<listitem>
<para>Setting this environment variable prevents a hard-coded
path to /tools/bin/sed.</para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term><parameter>- -disable-libmpx</parameter></term>
<listitem>
<para>This switch tells GCC to not build mpx (Memory Protection
Extensions) that can cause problems on some processors. It has
been removed from the next version of gcc.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><parameter>--with-system-zlib</parameter></term>
<listitem>
@ -170,12 +153,12 @@ rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/&gcc-version;/include-fixed/bits/</useri
for "historical" reasons.</para>
<screen><userinput remap="install">ln -sv ../usr/bin/cpp /lib</userinput></screen>
<!-- already done earlier
<para>Many packages use the name <command>cc</command> to call the C
compiler. To satisfy those packages, create a symlink:</para>
<screen><userinput remap="install">ln -sv gcc /usr/bin/cc</userinput></screen>
-->
<para>Add a compatibility symlink to enable building programs with
Link Time Optimization (LTO):</para>

View File

@ -43,13 +43,6 @@
<sect2 role="installation">
<title>Installation of Glibc</title>
<note><para>The Glibc build system is self-contained and will install
perfectly, even though the compiler specs file and linker are still
pointing to <filename class="directory">/tools</filename>. The specs
and linker cannot be adjusted before the Glibc install because the
Glibc autoconf tests would give false results and defeat the goal
of achieving a clean build.</para></note>
<para>Some of the Glibc programs use the non-FHS compliant
<filename class="directory">/var/db</filename> directory to store
their runtime data. Apply the following patch to make such programs
@ -66,7 +59,7 @@
<screen><userinput remap="pre">sed -i '/asm.socket.h/a# include &lt;linux/sockios.h&gt;' \
sysdeps/unix/sysv/linux/bits/socket.h</userinput></screen>
-->
=== already done ===
<para>Create a symlink for LSB
compliance. Additionally, for x86_64, create a compatibility symlink
required for the dynamic loader to function correctly:</para>
@ -78,7 +71,7 @@
ln -sfv ../lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
;;
esac</userinput></screen>
<!--
<para>Remove a file that may be left over from a previous build attempt:
</para>
@ -92,23 +85,25 @@ cd build</userinput></screen>
<para>Prepare Glibc for compilation:</para>
<screen><userinput remap="configure">CC="gcc -ffile-prefix-map=/tools=/usr" \
../configure --prefix=/usr \
--disable-werror \
--enable-kernel=&min-kernel; \
--enable-stack-protector=strong \
--with-headers=/usr/include \
<screen><userinput remap="configure">../configure --prefix=/usr \
--disable-werror \
--enable-kernel=&min-kernel; \
--enable-stack-protector=strong \
--with-headers=/usr/include \
libc_cv_slibdir=/lib</userinput></screen>
<variablelist>
<!-- WIP -->
<variablelist>
<title>The meaning of the options and new configure parameters:</title>
<varlistentry>
<term><parameter>CC="gcc -ffile-prefix-map=/tools=/usr"</parameter></term>
<term><parameter>CC="gcc -ffile-prefix-map=$LFS_DIR=$DIR"</parameter></term>
<listitem>
<para>Make GCC record any references to files in /tools in result
of the compilation as if the files resided in /usr. This avoids
introduction of invalid paths in debugging symbols.</para>
<para>Make GCC record any references to files in <filename
class="directory">/usr/lib/gcc/x86_64-lfs-linux-gnu</filename>
in result of the compilation as if the files resided in <filename
class="directory">/usr/lib/gcc/x86_64-pc-linux-gnu</filename>.
This avoids introduction of invalid paths in debugging
symbols.</para>
</listitem>
</varlistentry>
@ -128,13 +123,12 @@ cd build</userinput></screen>
smashing attacks.</para>
</listitem>
</varlistentry>
<!-- do we need this one? -->
<varlistentry>
<term><parameter>--with-headers=/usr/include</parameter></term>
<listitem>
<para>This option tells the build system where to find the
kernel API headers. By default, those headers are sought in
<filename class="directory">/tools/include</filename>.</para>
kernel API headers.</para>
</listitem>
</varlistentry>

View File

@ -36,15 +36,6 @@
optimizations. The subsequent system will still run very fast and be stable
at the same time.</para>
<para>The order that packages are installed in this chapter needs to be
strictly followed to ensure that no program accidentally acquires a path
referring to <filename class="directory">/tools</filename> hard-wired into
it. For the same reason, do not compile separate packages in parallel.
Compiling in parallel may save time (especially on dual-CPU machines), but it
could result in a program containing a hard-wired path to <filename
class="directory">/tools</filename>, which will cause the program to stop
working when that directory is removed.</para>
<para>Before the installation instructions, each installation page provides
information about the package, including a concise description of what it
contains, approximately how long it will take to build, and how much disk

View File

@ -60,20 +60,11 @@ sed -i 's/resizecons.8 //' docs/man/man8/Makefile.in</userinput></screen>
<para>Prepare Kbd for compilation:</para>
<screen><userinput remap="configure">PKG_CONFIG_PATH=/tools/lib/pkgconfig ./configure --prefix=/usr --disable-vlock</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/usr --disable-vlock</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<!--
<varlistentry>
<term><parameter>- -datadir=/lib/kbd</parameter></term>
<listitem>
<para>This option puts keyboard layout data in a directory that will
always be on the root partition instead of the default <filename
class="directory">/usr/share/kbd</filename>.</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term><parameter>--disable-vlock</parameter></term>
<listitem>
@ -104,16 +95,6 @@ sed -i 's/resizecons.8 //' docs/man/man8/Makefile.in</userinput></screen>
such languages have to download working keymaps separately.</para>
</note>
<!--
<para>Some of the scripts in the LFS-Bootscripts package depend on
<command>kbd_mode</command>, <command>loadkeys</command>,
<command>openvt</command>, and
<command>setfont</command>. As <filename class="directory">/usr</filename>
may not be available during the early stages of booting, those binaries
need to be on the root partition:</para>
<screen><userinput remap="install">mv -v /usr/bin/{kbd_mode,loadkeys,openvt,setfont} /bin</userinput></screen>
-->
<para>If desired, install the documentation:</para>
<screen><userinput remap="install">mkdir -v /usr/share/doc/kbd-&kbd-version;

View File

@ -45,22 +45,6 @@
<screen><userinput remap="configure">./configure --prefix=/usr</userinput></screen>
<!--
<screen><userinput remap="configure">PKG_CONFIG_PATH=/tools/lib/pkgconfig ./configure - -prefix=/usr</userinput></screen>
<variablelist>
<title>The meaning of the configure options:</title>
<varlistentry>
<term><parameter>PKG_CONFIG_PATH</parameter></term>
<listitem>
<para>Use pkg-config to obtain the location of the test
library metadata built in <xref linkend="ch-system-check"/>.</para>
</listitem>
</varlistentry>
</variablelist>
-->
<para>Compile the package:</para>
<screen><userinput remap="make">make</userinput></screen>

View File

@ -1,209 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../general.ent">
%general-entities;
]>
<sect1 id="ch-system-linux-headers" role="wrap">
<?dbhtml filename="linux-headers.html"?>
<sect1info condition="script">
<productname>linux-headers</productname>
<productnumber>&linux-version;</productnumber>
<address>&linux-url;</address>
</sect1info>
<title>Linux-&linux-version; API Headers</title>
<indexterm zone="ch-system-linux-headers">
<primary sortas="a-Linux">Linux</primary>
<secondary>API headers</secondary>
</indexterm>
<sect2 role="package">
<title/>
<para>The Linux API Headers (in linux-&linux-version;.tar.xz) expose the
kernel's API for use by Glibc.</para>
<segmentedlist>
<segtitle>&buildtime;</segtitle>
<segtitle>&diskspace;</segtitle>
<seglistitem>
<seg>&linux-headers-ch6-sbu;</seg>
<seg>&linux-headers-ch6-du;</seg>
</seglistitem>
</segmentedlist>
</sect2>
<sect2 role="installation">
<title>Installation of Linux API Headers</title>
<para>The Linux kernel needs to expose an Application Programming Interface
(API) for the system's C library (Glibc in LFS) to use. This is done
by way of sanitizing various C header files that are shipped in the Linux
kernel source tarball.</para>
<para>Make sure there are no stale files and dependencies lying around
from previous activity:</para>
<screen><userinput remap="pre">make mrproper</userinput></screen>
<para>Now extract the user-visible kernel headers from the source.
The recommended make target <quote>headers_install</quote> cannot be
used, because it requires <application>rsync</application>, which is
not available in <filename class="directory">/tools</filename>. The
headers are first placed in <filename class="directory">./usr</filename>,
then some files used by the kernel developers are removed, then
the files are copied to their final location.</para>
<screen><userinput remap="make">make headers
find usr/include -name '.*' -delete
rm usr/include/Makefile
</userinput><userinput remap="install">cp -rv usr/include/* /usr/include</userinput></screen>
</sect2>
<sect2 id="contents-linux-headers" role="content">
<title>Contents of Linux API Headers</title>
<segmentedlist>
<segtitle>Installed headers</segtitle>
<segtitle>Installed directories</segtitle>
<seglistitem>
<seg>/usr/include/asm/*.h, /usr/include/asm-generic/*.h,
/usr/include/drm/*.h, /usr/include/linux/*.h, /usr/include/misc/*.h,
/usr/include/mtd/*.h, /usr/include/rdma/*.h, /usr/include/scsi/*.h,
/usr/include/sound/*.h, /usr/include/video/*.h,
and /usr/include/xen/*.h</seg>
<seg>/usr/include/asm, /usr/include/asm-generic, /usr/include/drm,
/usr/include/linux, /usr/include/misc, /usr/include/mtd,
/usr/include/rdma, /usr/include/scsi, /usr/include/sound,
/usr/include/video, and /usr/include/xen</seg>
</seglistitem>
</segmentedlist>
<variablelist>
<bridgehead renderas="sect3">Short Descriptions</bridgehead>
<?dbfo list-presentation="list"?>
<?dbhtml list-presentation="table"?>
<varlistentry id="asm">
<term><filename class="headerfile">/usr/include/asm/*.h</filename></term>
<listitem>
<para>The Linux API ASM Headers</para>
<indexterm zone="ch-system-linux-headers asm">
<primary sortas="e-/usr/include/asm/*.h">/usr/include/asm/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="asm-generic">
<term><filename class="headerfile">/usr/include/asm-generic/*.h</filename></term>
<listitem>
<para>The Linux API ASM Generic Headers</para>
<indexterm zone="ch-system-linux-headers asm-generic">
<primary sortas="e-/usr/include/asm-generic/*.h">/usr/include/asm-generic/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="drm">
<term><filename class="headerfile">/usr/include/drm/*.h</filename></term>
<listitem>
<para>The Linux API DRM Headers</para>
<indexterm zone="ch-system-linux-headers drm">
<primary sortas="e-/usr/include/drm/*.h">/usr/include/drm/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="linux">
<term><filename class="headerfile">/usr/include/linux/*.h</filename></term>
<listitem>
<para>The Linux API Linux Headers</para>
<indexterm zone="ch-system-linux-headers linux">
<primary sortas="e-/usr/include/linux/*.h">/usr/include/linux/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="misc">
<term><filename class="headerfile">/usr/include/misc/*.h</filename></term>
<listitem>
<para>The Linux API Miscellaneous Headers</para>
<indexterm zone="ch-system-linux-headers misc">
<primary sortas="e-/usr/include/misc/*.h">/usr/include/misc/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="mtd">
<term><filename class="headerfile">/usr/include/mtd/*.h</filename></term>
<listitem>
<para>The Linux API MTD Headers</para>
<indexterm zone="ch-system-linux-headers mtd">
<primary sortas="e-/usr/include/mtd/*.h">/usr/include/mtd/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="rdma">
<term><filename class="headerfile">/usr/include/rdma/*.h</filename></term>
<listitem>
<para>The Linux API RDMA Headers</para>
<indexterm zone="ch-system-linux-headers rdma">
<primary sortas="e-/usr/include/rdma/*.h">/usr/include/rdma/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="scsi">
<term><filename class="headerfile">/usr/include/scsi/*.h</filename></term>
<listitem>
<para>The Linux API SCSI Headers</para>
<indexterm zone="ch-system-linux-headers scsi">
<primary sortas="e-/usr/include/scsi/*.h">/usr/include/scsi/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="sound">
<term><filename class="headerfile">/usr/include/sound/*.h</filename></term>
<listitem>
<para>The Linux API Sound Headers</para>
<indexterm zone="ch-system-linux-headers sound">
<primary sortas="e-/usr/include/sound/*.h">/usr/include/sound/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="video">
<term><filename class="headerfile">/usr/include/video/*.h</filename></term>
<listitem>
<para>The Linux API Video Headers</para>
<indexterm zone="ch-system-linux-headers video">
<primary sortas="e-/usr/include/video/*.h">/usr/include/video/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
<varlistentry id="xen">
<term><filename class="headerfile">/usr/include/xen/*.h</filename></term>
<listitem>
<para>The Linux API Xen Headers</para>
<indexterm zone="ch-system-linux-headers xen">
<primary sortas="e-/usr/include/xen/*.h">/usr/include/xen/*.h</primary>
</indexterm>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>

View File

@ -73,13 +73,13 @@ sed -i '/{OLDSUFF}/c:' support/shlib-install</userinput></screen>
<para>Compile the package:</para>
<screen><userinput remap="make">make SHLIB_LIBS="-L/tools/lib -lncursesw"</userinput></screen>
<screen><userinput remap="make">make SHLIB_LIBS="-lncursesw"</userinput></screen>
<variablelist>
<title>The meaning of the make option:</title>
<varlistentry>
<term><parameter>SHLIB_LIBS="-L/tools/lib -lncursesw"</parameter></term>
<term><parameter>SHLIB_LIBS="-lncursesw"</parameter></term>
<listitem>
<para>This option forces Readline to link against the
<filename class="libraryfile">libncursesw</filename> library.</para>
@ -92,7 +92,7 @@ sed -i '/{OLDSUFF}/c:' support/shlib-install</userinput></screen>
<para>Install the package:</para>
<screen><userinput remap="install">make SHLIB_LIBS="-L/tools/lib -lncursesw" install</userinput></screen>
<screen><userinput remap="install">make SHLIB_LIBS="-lncursesw" install</userinput></screen>
<para>Now move the dynamic libraries to a more appropriate location
and fix up some permissions and symbolic links:</para>

View File

@ -26,18 +26,9 @@ chroot "$LFS" /usr/bin/env -i \
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
/bin/bash --login</userinput></screen>
<para>The reason for this is that the programs in <filename
class="directory">/tools</filename> are no longer needed. For this reason
you can delete the <filename class="directory">/tools</filename>
directory if so desired.</para>
<note>
<para>Removing <filename class="directory">/tools</filename> will also
remove the temporary copies of Tcl, Expect, and DejaGNU which were used
for running the toolchain tests. If you need these programs later on,
they will need to be recompiled and re-installed. The BLFS book has
instructions for this (see <ulink url="&blfs-root;"/>).</para>
</note>
<para>Here the <parameter>+h</parameter> option is not used anymore, since
all the previous programs have been replaced: hashing is therefore
possible.</para>
<para>If the virtual kernel file systems have been unmounted, either manually
or through a reboot, ensure that the virtual kernel file systems are mounted

View File

@ -42,24 +42,12 @@
<para>First fix an issue in the LFS environment and remove a failing test:</para>
<screen><userinput remap="pre">sed -i 's/usr/tools/' build-aux/help2man
sed -i 's/testsuite.panic-tests.sh//' Makefile.in</userinput></screen>
<screen><userinput remap="pre">sed -i 's/testsuite.panic-tests.sh//' Makefile.in</userinput></screen>
<para>Prepare Sed for compilation:</para>
<screen><userinput remap="configure">./configure --prefix=/usr --bindir=/bin</userinput></screen>
<!--
<variablelist>
<title>The meaning of the new configure option:</title>
<varlistentry>
<term><parameter>-i -htmldir</parameter></term>
<listitem>
<para>This sets the installation directory for the HTML documentation.</para>
</listitem>
</varlistentry>
</variablelist>
-->
<para>Compile the package and generate the HTML documentation:</para>
<screen><userinput remap="make">make

View File

@ -84,7 +84,8 @@ find man -name Makefile.in -exec sed -i 's/passwd\.5 / /' {} \;</userinput></s
<para>Prepare Shadow for compilation:</para>
<screen><userinput remap="configure">touch /usr/bin/passwd
./configure --sysconfdir=/etc --with-group-name-max-length=32</userinput></screen>
./configure --sysconfdir=/etc \
--with-group-name-max-length=32</userinput></screen>
<variablelist>
<title>The meaning of the configure option:</title>

View File

@ -56,38 +56,22 @@ done
unset LIB save_lib save_usrlib</userinput></screen>
<para>Before performing the stripping, take special care to ensure that
<!-- <para>Before performing the stripping, take special care to ensure that
none of the binaries that are about to be stripped are running:</para>
<screen role="nodump"><userinput>exec /tools/bin/bash</userinput></screen>
<!--
If
unsure whether the user entered chroot with the command given in
<xref linkend="ch-system-chroot" role=","/> first use the version
of bash we created in
chroot:</para>
<screen role="nodump"><userinput>logout</userinput></screen>
<para>Then reenter it with:</para>
<screen role="nodump"><userinput>chroot $LFS /tools/bin/env -i \
HOME=/root TERM=$TERM \
PS1='(lfs chroot) \u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
/tools/bin/bash - -login</userinput></screen>-->
<para>Now the binaries and libraries can be safely stripped:</para>
-->
<para>Now the binaries and libraries can be stripped:</para>
<screen><userinput>find /usr/lib -type f -name \*.a \
-exec strip --strip-debug {} ';'
<screen><userinput>/tools/bin/find /usr/lib -type f -name \*.a \
-exec /tools/bin/strip --strip-debug {} ';'
find /lib /usr/lib -type f -name \*.so* ! -name \*dbg \
-exec strip --strip-unneeded {} ';'
/tools/bin/find /lib /usr/lib -type f \( -name \*.so* -a ! -name \*dbg \) \
-exec /tools/bin/strip --strip-unneeded {} ';'
/tools/bin/find /{bin,sbin} /usr/{bin,sbin,libexec} -type f \
-exec /tools/bin/strip --strip-all {} ';'</userinput></screen>
find /{bin,sbin} /usr/{bin,sbin,libexec} -type f \
-exec strip --strip-all {} ';'</userinput></screen>
<para>A large number of files will be reported as having their file
format not recognized. These warnings can be safely ignored. These

View File

@ -48,7 +48,7 @@
<para>Create a symlink to work around missing xsltproc:</para>
<screen><userinput remap="pre">ln -sf /tools/bin/true /usr/bin/xsltproc</userinput></screen>
<screen><userinput remap="pre">ln -sf /bin/true /usr/bin/xsltproc</userinput></screen>
<para>Set up the man pages:</para>
@ -101,9 +101,7 @@ meson --prefix=/usr \
<term><parameter>-D*-path=*</parameter></term>
<listitem>
<para>These switches provide location of binaries needed by
systemd at runtime that have not yet been installed, or who's
pkgconfig files are currently only in
<filename>/tools/lib/pkgconfig</filename>.</para>
systemd at runtime that have not yet been installed.</para>
</listitem>
</varlistentry>

View File

@ -54,18 +54,6 @@
<sect2 role="installation">
<title>Installation of Util-linux</title>
<!--
<para>First, fix one of the regression tests:</para>
<screen><userinput remap="pre">sed -e 's/2^64/(2^64/' -e 's/E &lt;/E) &lt;=/' -e 's/ne /eq /' \
-i tests/ts/ipcs/limits2</userinput></screen>
-->
<para>Remove the earlier created symlinks and files:</para>
<screen><userinput remap="pre">rm -vf /usr/include/{blkid,libfdisk,libmount,uuid}
rm -vf /usr/lib/lib{blkid,fdisk,mount,uuid}.so*
rm -vf /usr/lib/pkgconfig/{blkid,fdisk,mount,uuid}.pc</userinput></screen>
<para>Prepare Util-linux for compilation:</para>

View File

@ -299,7 +299,7 @@ cp -r Documentation/* /usr/share/doc/linux-&linux-version;</userinput></screen>
class="directory">/usr/include</filename>) should
<emphasis>always</emphasis> be the ones against which Glibc was compiled,
that is, the sanitised headers installed in <xref
linkend="ch-system-linux-headers"/>. Therefore, they should
linkend="ch-tools-linux-headers"/>. Therefore, they should
<emphasis>never</emphasis> be replaced by either the raw kernel headers
or any other kernel sanitized headers.</para>
</warning>