gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-06-19 03:39:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Shifting chapter contents, and moving preparational sections of chapter 5 to a separate chapter.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3284 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud 2004-03-07 12:09:31 +00:00
parent 4f4b4e84a2
commit c6b5ddb7a6
16 changed files with 849 additions and 841 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
book.xml
View File

@ -11,11 +11,11 @@
<part id="part1">
<title>Part I - Introduction</title>
&chapter01;
&chapter02;
</part>
<part id="part2">
<title>Part II - Preparing for the build</title>
&chapter02;
&chapter03;
&chapter04;
&chapter05;

103
chapter01/askforhelp.xml Normal file
View File

@ -0,0 +1,103 @@
<sect1 id="prepare-askforhelp">
<title>How to ask for help</title>
<?dbhtml filename="askforhelp.html" dir="chapter02"?>
<para>If you encounter a problem while using this book, and your problem
is not listed in the FAQ (<ulink url="&faq-root;"/>), you will find that
most of the people on Internet Relay Chat (IRC) and on the mailing lists
are willing to help you (see <xref linkend="ch-scatter-administrativa"/>.
To assist us in diagnosing and solving your problem, include as much relevant
information as possible in your request for help.</para>
<sect2>
<title>Things to mention</title>
<para>Apart from a brief explanation of the problem you're having, the
essential things to include in your request are:</para>
<itemizedlist>
<listitem><para>the version of the book you are using (being &version;),</para></listitem>
<listitem><para>the host distribution and version you are using to create
LFS from,</para></listitem>
<listitem><para>the package or section giving you problems,</para></listitem>
<listitem><para>the exact error message or symptom you are receiving,</para></listitem>
<listitem><para>whether you have deviated from the book at all.</para></listitem>
</itemizedlist>
<para>(Note that saying that you've deviated from the book doesn't mean
that we won't help you. After all, LFS is about choice. It'll just
help us to see other possible causes of your problem.)</para>
</sect2>
<sect2>
<title>Configure problems</title>
<para>When something goes wrong during the stage where the configure script
is run, look through the <filename>config.log</filename> file. This file
may contain errors encountered during configure which weren't printed to
the screen. Include those relevant lines if you decide to ask for
help.</para>
</sect2>
<sect2>
<title>Compile problems</title>
<para>To help us find the cause of the problem, both screen output and
the contents of various files are useful. The screen output from both
the ./configure script and the make run can be useful. Don't blindly
include the whole thing but on the other hand, don't include too little.
As an example, here is some screen output from make:</para>
<screen>gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-DLOCALEDIR=\"/mnt/lfs/usr/share/locale\" -DLIBDIR=\"/mnt/lfs/usr/lib\"
-DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o expand.o file.o
function.o getopt.o implicit.o job.o main.o misc.o read.o remake.o rule.o
signame.o variable.o vpath.o default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2</screen>
<para>In this case, many people just include the bottom section where it
says:</para>
<screen>make [2]: *** [make] Error 1</screen>
<para>and onwards. This isn't enough for us to diagnose the problem because it
only tells us that <emphasis>something</emphasis> went wrong, not
<emphasis>what</emphasis> went wrong. The whole section, as in the example
above, is what should be included to be helpful, because it includes the
command that was executed and the command's error message(s).</para>
<para>An excellent article on asking for help on the Internet in general
has been written by Eric S. Raymond. It is available online at <ulink
url="http://catb.org/~esr/faqs/smart-questions.html"/>.
Read and follow the hints in that document and you are much more likely
to get a response to start with and also to get the help you actually
need.</para>
</sect2>
<sect2>
<title>Test suite problems</title>
<para>Many packages provide a test suite which, depending on the importance
of the package, we may encourage you to run. Sometimes packages will
generate false or expected failures. If you encounter these, you can check
the LFS Wiki page at <ulink url="&wiki-root;"/> to see whether we have
already noted and investigated them. If we already know
about them, then usually there is no need to be concerned.</para>
</sect2>
</sect1>

1
chapter01/chapter01.xml
View File

@ -5,5 +5,6 @@
&c1-how;
&c1-changelog;
&c1-resources;
&c1-askforhelp;
</chapter>

2
chapter01/contactinfo.xml
View File

@ -27,7 +27,7 @@ support channel is named #LFS-support.</para>
</sect2>
<sect2 id="ch-scatter-maillists" xreflabel="Chapter 1 - Mailing lists">
<sect2 id="ch-scatter-maillists">
<title>Mailing lists</title>
<para>The <emphasis>linuxfromscratch.org</emphasis> server is hosting a number

87
chapter01/how.xml
View File

@ -9,62 +9,57 @@ programs like a compiler, linker and shell to build the new system. Normally
all the required tools are available if you selected <quote>development</quote>
as one of the options when you installed your distribution.</para>
<para>In <xref linkend="chapter-making-space"/> you will first create a new Linux native
<para>In <xref linkend="chapter-making-space"/> you will first create a new
partition and file system, the place where your new LFS system will be compiled
and installed. Then in <xref linkend="chapter-getting-materials"/> you download all the
packages and patches required to build an LFS system, and store them on the new
file system.</para>
and installed. Then in <xref linkend="chapter-getting-materials"/> you download
all the packages and patches needed to build an LFS system, and store them on
the new file system. In <xref linkend="chapter-preparation"/> you set up a good
environment to work in.</para>
<para><xref linkend="chapter-temporary-tools"/> then discusses 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 -- for example, to compile
a compiler you need a compiler.</para>
<para><xref linkend="chapter-temporary-tools"/> then discusses the installation
of a number of packages that form the basic development suite used to build the
actual system in <xref linkend="chapter-building-system"/>.</para>
<para>The first thing to be done in <xref linkend="chapter-temporary-tools"/> is build a
first pass of the toolchain, made up of Binutils and GCC. The programs from
these packages will be linked statically in order for them to be usable
independently of the host system. The second thing to do is build Glibc, the
C library. Glibc will be compiled by the toolchain programs we just built in
the first pass. The third thing to do is build a second pass of the toolchain.
This time the toolchain will be dynamically linked against the newly built
Glibc. The remaining <xref linkend="chapter-temporary-tools"/> packages are all built using
this second pass toolchain and dynamically linked against the new
host-independent Glibc. When this is done, the LFS installation process will no
longer depend on the host distribution, with the exception of the running
kernel.</para>
<para>The first thing to be done in <xref linkend="chapter-temporary-tools"/>
is build a first pass of the <emphasis>toolchain</emphasis>, consisting of
Binutils and GCC. The programs from these packages will be linked statically in
order for them to be usable independently of the host system (thus making it
in theory possible to skip the second passes). The second thing to do is build
Glibc, the C library. Glibc will be compiled by the just-built toolchain
programs. The third thing to do is build a second pass of the toolchain, this
time linking it dynamically against the newly built Glibc. The remaining <xref
linkend="chapter-temporary-tools"/> packages are all built using this second
pass toolchain and are dynamically linked against the new host-independent
Glibc. When this is done, the LFS installation process will no longer depend on
the host distribution, with the exception of the running kernel.</para>
<para>You may be thinking that <quote>this seems like a lot of work, just to
get away from my host distribution</quote>. Well, a full technical explanation
is provided at the start of <xref linkend="chapter-temporary-tools"/>, including some notes
on the differences between statically and dynamically linked programs.</para>
is provided at the start of <xref linkend="chapter-temporary-tools"/>,
including some notes on the differences between statically and dynamically
linked programs.</para>
<para>In <xref linkend="chapter-building-system"/> your real LFS system will be built. The
chroot (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 reason that you don't actually reboot, but instead
chroot, is that creating a bootable system requires additional work which isn't
necessary just yet. But the major advantage is that chrooting allows you to
continue using the host while LFS is being built. While waiting for package
compilation to complete, you can simply switch to a different VC (Virtual
Console) or X desktop and continue using the computer as you normally
would.</para>
<para>In <xref linkend="chapter-building-system"/> your real LFS system will be
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 reason that you don't
actually reboot, but instead chroot, is that creating a bootable system
requires additional work which isn't necessary just yet. But the major
advantage is that chrooting allows you to continue using the host while LFS is
being built. While waiting for package compilation to complete, you can simply
switch to a different VC (Virtual Console) or X desktop and continue using the
computer as you normally would.</para>
<para>To finish the installation, the bootscripts are set up in
<xref linkend="chapter-bootscripts"/>, the kernel and bootloader are set up in
<xref linkend="chapter-mixture"/>, and <xref linkend="chapter-finalizing"/> contains some
pointers to help you after you finish the book. Then, finally, you're ready to
reboot your computer into your new LFS system.</para>
<xref linkend="chapter-mixture"/>, and <xref linkend="chapter-finalizing"/>
contains some pointers to help you after you finish the book. Then, finally,
you're ready to reboot your computer into your new LFS system.</para>
<para>This is the process in a nutshell. Detailed information on the steps you
will take are discussed in the chapters and package descriptions as you
progress through them. If something isn't completely clear now, don't worry,
everything will fall into place soon.</para>
<para>Please read <xref linkend="chapter-preparation"/> carefully as it explains a few
important things you should be aware of before you begin to work through
<xref linkend="chapter-temporary-tools"/> and beyond.</para>
<para>This is the process in a nutshell. Detailed information on all the steps
taken is given in the chapters and sections as you progress through them. If
something isn't completely clear now, don't worry, everything will fall into
place soon.</para>
</sect1>

57
chapter02/aboutdependencies.xml
View File

@ -1,57 +0,0 @@
<sect1 id="prepare-aboutdependencies">
<title>About dependencies</title>
<?dbhtml filename="aboutdependencies.html" dir="chapter02"?>
<!-- Leave this file in the repo until we figure out finally what to do with
dependencies -->
<para>There are a few ways to compile a list of a package's installation
dependencies. What we consider the best way is using the
<command>strace</command> program available at <ulink
url="http://www.wi.leidenuniv.nl/~wichert/strace/"/>.</para>
<para><command>strace</command> is a program that provides a trace of all
system calls made by another program. One of the most useful system calls
to trace when figuring out dependencies is the <emphasis>execve(2)</emphasis>
system call, which is used to execute programs (see its man page for
all the details). Whenever you run a program, be it from a shell or via a
configure script or Makefile file, the execve call is made. If you trace
these calls, you will know what programs were executed behind the
scenes.</para>
<para>Here is a line of output from running a configure script:</para>
<screen>19580 execve("/bin/rm", ["rm", "-f", "conf19538", "conf19538.exe", "conf19538.file"], [/* 26 vars */]) = 0</screen>
<para>This line tells us that the <command>/bin/rm</command> program was
run with a PID of 19580, which command line parameters it was given (rm -f
conf195838 conf19538.exe conf19538.file) and its exit value (0).</para>
<para>For dependency purposes all we care about is that
<command>/bin/rm</command> was run during the configure script, so this is
an installation dependency. Without <command>rm</command>, the script
wouldn't be able to run properly.</para>
<para>Unfortunately, this method is not foolproof. Configure scripts check
for the presense of many programs, but not all of them are considered real
dependencies. For instance, configure scripts may check for the presence of
the <command>autoconf</command> program. It will be listed in the strace
output, but it's not a real installation dependency. A package will in most
if not all cases install just fine without that program. There are other
such false positives.</para>
<para>This means automatic dependency gathering is never accurate. You will
always need to validate the list and figure out the false positives. In
some (rare) cases autoconf might be a real dependency, so you
can't simply ignore all autoconf entries. A manual validation really is a
requirement for an accurate list.</para>
<para>This book is not so verbose as to list exactly which program from which
package is required for a successful installation (we used to, but it had
become too much work to maintain it). The book will contain simply the
names of packages you need to have installed. If you need the verbosity
in the form of "package a needs file b and c from package d", have a look
at &lt;enter URL when it's available&gt;.</para>
</sect1>

32
chapter02/aboutlfs.xml
View File

@ -1,32 +0,0 @@
<sect1 id="prepare-aboutlfs">
<title>About $LFS</title>
<?dbhtml filename="aboutlfs.html" dir="chapter02"?>
<para>Please read the following paragraphs carefully. Throughout this book the
variable LFS will be used frequently. $LFS must at all times be replaced with
the directory where the partition that contains the LFS system is mounted. How
to create and where to mount the partition will be explained in full detail in
<xref linkend="chapter-making-space"/>. For the moment let's assume that the LFS partition
is mounted on <filename>/mnt/lfs</filename>.</para>
<para>When you are told to run a command like
<userinput>./configure --prefix=$LFS/tools</userinput>, you actually have to
execute <userinput>./configure --prefix=/mnt/lfs/tools</userinput>.</para>
<para>It's important that this is done no matter where it is read; be it in
commands entered in a shell, or in a file edited or created.</para>
<para>A possible solution is to set the environment variable LFS.
This way $LFS can be entered literally instead of replacing it with
/mnt/lfs. This is accomplished by running: </para>
<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
<para>Now, if you are told to run a command such as
<userinput>./configure --prefix=$LFS/tools</userinput>, then you may type it
literally. Your shell will replace "$LFS" with "/mnt/lfs" when it processes
the command line (that is, when you hit Enter after having typed the
command).</para>
</sect1>

39
chapter02/aboutsbus.xml
View File

@ -1,39 +0,0 @@
<sect1 id="prepare-aboutsbus">
<title>About SBUs</title>
<?dbhtml filename="aboutsbus.html" dir="chapter02"?>
<para>Most people would like to know beforehand how long it approximately
takes to compile and install each package. But "Linux from Scratch" is built
on so many different systems, it is not possible to give actual times that are
anywhere near accurate: the biggest package (Glibc) won't take more than
twenty minutes on the fastest systems, but will take something like three days
on the slowest -- no kidding. So instead of giving actual times, we've come up
with the idea of using the <emphasis>Static Binutils Unit</emphasis>
(abbreviated to <emphasis>SBU</emphasis>).</para>
<para>It works like this: the first package you compile in this book is the
statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it
takes to compile this package is what we call the "Static Binutils Unit" or
"SBU". All other compile times will be expressed relative to this time.</para>
<para>For example, the time it takes to build the static version of GCC is
&gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes
to compile and install the static Binutils, then you know it will take
approximately 45 minutes to build the static GCC. Fortunately, most build times
are much shorter than the one of Binutils.</para>
<para>Note that if the system compiler on your host is GCC-2 based, the SBUs
listed may end up being somewhat understated. This is because the SBU is based
on the very first package, compiled with the old GCC, while the rest of the
system is compiled with the newer GCC-&gcc-version; which is known to be
approximately 30% slower.</para>
<para>Also note that SBUs don't work well for SMP-based machines. But if you're
so lucky as to have multiple processors, chances are that your system is so fast
that you won't mind.</para>
<para>If you wish to see actual timings for specific machines, have a look at
<ulink url="&lfs-root;~bdubbs/"/>.</para>
</sect1>

40
chapter02/abouttestsuites.xml
View File

@ -1,40 +0,0 @@
<sect1 id="prepare-abouttestsuites">
<title>About the test suites</title>
<?dbhtml filename="abouttestsuites.html" dir="chapter02"?>
<para>Most packages provide a test suite. Running the test suite for a newly
built package is generally a good idea, as it can provide a nice sanity check
that everything compiled correctly. A test suite that passes its set of checks
usually proves that the package is functioning as the developer intended. It
does not, however, guarantee that the package is totally bug free.</para>
<para>Some test suites are more important than others. For example, the test
suites for the core toolchain packages -- GCC, Binutils, and Glibc -- are of
the utmost importance due to their central role in a properly functioning
system. But be warned, the test suites for GCC and Glibc can take a very long
time to complete, especially on slower hardware.</para>
<note><para>Experience has shown us 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 weird and inexplicable failures. Not only
that, the tools built in <xref linkend="chapter-temporary-tools"/> are
temporary and eventually discarded. For the average reader of this book we
recommend <emphasis>not</emphasis> to run the test suites in <xref
linkend="chapter-temporary-tools"/>. The instructions for running those test
suites are still provided for the benefit of testers and developers, but they
are strictly optional for everyone else.</para></note>
<para>A common problem when running the test suites for Binutils and GCC is
running out of pseudo terminals (PTYs for short). The symptom is a very high
number of failing tests. This can happen for several reasons, but the most
likely cause is that the host system doesn't have the
<emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
more detail later on in <xref linkend="chapter-temporary-tools"/>.</para>
<para>Sometimes package test suites will give false failures. You can
consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
failures are normal. This applies to all tests throughout the book.</para>
</sect1>

137
chapter02/chapter02.xml
View File

@ -1,10 +1,135 @@
<chapter id="chapter-preparation" xreflabel="Chapter 2">
<title>Important information</title>
<chapter id="chapter-making-space" xreflabel="Chapter 2">
<title>Preparing a new partition</title>
<?dbhtml filename="chapter02.html" dir="chapter02"?>
&c2-aboutlfs;
&c2-aboutsbus;
&c2-abouttestsuites;
&c2-askforhelp;
<sect1 id="space-introduction">
<title>Introduction</title>
<?dbhtml filename="introduction.html" dir="chapter02"?>
<para>In this chapter the partition which will host the LFS system is
prepared. We will create the partition itself, make a file system on it,
and mount it.</para>
</sect1>
<sect1 id="space-creatingpartition">
<title>Creating a new partition</title>
<?dbhtml filename="creatingpartition.html" dir="chapter02"?>
<para>In order to build our new Linux system, we will need some space:
an empty disk partition. If you don't have a free partition, and no room
on any of your hard disks to make one, then you could build LFS on the
same partition as the one on which your current distribution is installed.
This procedure is not recommended for your first LFS install, but if you
are short on disk space, and you feel brave, take a look at the hint at
<ulink url="&hints-root;lfs_next_to_existing_systems.txt"/>.</para>
<para>For a minimal system you will need a partition of around 1.2 GB.
This is enough to store all the source tarballs and compile all the packages.
But if you intend to use the LFS system as your primary Linux system, you
will probably want to install additional software, and will need more space
than this, probably around 2 or 3 GB.</para>
<para>As we almost never have enough RAM in our box, it is a good idea to
use a small disk partition as swap space -- this space is used by the kernel
to store seldom-used data to make room in memory for more urgent stuff.
The swap partition for your LFS system can be the same one as for your host
system, so you won't have to create another if your host system already uses
a swap partition.</para>
<para>Start a disk partitioning program such as <command>cfdisk</command>
or <command>fdisk</command> with an argument naming the hard disk upon
which the new partition must be created -- for example
<filename>/dev/hda</filename> for the primary IDE disk. Create a Linux native
partition and a swap partition, if needed. Please refer to the man pages of
<command>cfdisk</command> or <command>fdisk</command> if you don't yet
know how to use the programs.</para>
<para>Remember the designation of your new partition -- something like
<filename>hda5</filename>. This book will refer to it as the LFS partition.
If you (now) also have a swap partition, remember its designation too. These
names will later be needed for the <filename>/etc/fstab</filename> file.</para>
</sect1>
<sect1 id="space-creatingfilesystem">
<title>Creating a file system on the new partition</title>
<?dbhtml filename="creatingfilesystem.html" dir="chapter02"?>
<para>Now that we have a blank partition, we can create a file system on it.
Most widely used in the Linux world is the second extended file system (ext2),
but with the high-capacity hard disks of today the so-called journaling
file systems are becoming increasingly popular. Here we will create an ext2
file system, but build instructions for other file systems can be found at
<ulink url="&blfs-root;view/stable/postlfs/filesystems.html"/>.</para>
<para>To create an ext2 file system on the LFS partition run the following:</para>
<screen><userinput>mke2fs /dev/xxx</userinput></screen>
<para>Replace <filename>xxx</filename> with the name of the LFS partition
(something like <filename>hda5</filename>).</para>
<para>If you created a (new) swap partition you need to initialize it as a
swap partition too (also known as formatting, like you did above with
<command>mke2fs</command>) by running:</para>
<screen><userinput>mkswap /dev/yyy</userinput></screen>
<para>Replace <filename>yyy</filename> with the name of the swap
partition.</para>
</sect1>
<sect1 id="space-mounting">
<title>Mounting the new partition</title>
<?dbhtml filename="mounting.html" dir="chapter02"?>
<para>Now that we've created a file system, we want to be able to access
the partition. For that, we need to mount it, and have to choose a mount
point. In this book we assume that the file system is mounted under
<filename>/mnt/lfs</filename>, but it doesn't matter what directory
you choose.</para>
<para>Choose a mount point and assign it to the LFS environment variable
by running:</para>
<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
<para>Now create the mount point and mount the LFS file system by running:</para>
<screen><userinput>mkdir -p $LFS
mount /dev/xxx $LFS</userinput></screen>
<para>Replace <filename>xxx</filename> with the designation of the LFS
partition.</para>
<para>If you have decided to use multiple partitions for LFS (say one for
<filename>/</filename> and another for <filename>/usr</filename>), mount
them like this:</para>
<screen><userinput>mkdir -p $LFS
mount /dev/xxx $LFS
mkdir $LFS/usr
mount /dev/yyy $LFS/usr</userinput></screen>
<para>Of course, replace <filename>xxx</filename> and <filename>yyy</filename>
with the appropriate partition names.</para>
<para>You should also ensure that this new partition is not mounted with
permissions that are too restrictive (such as the nosuid, nodev or noatime
options). You can run the <command>mount</command> command without any
parameters to see with what options the LFS partition is mounted. If
you see nosuid, nodev or noatime, you will need to remount it.</para>
<para>Now that we've made ourselves a place to work in, we're ready to download
the packages.</para>
</sect1>
</chapter>

401
chapter03/chapter03.xml
View File

@ -1,135 +1,326 @@
<chapter id="chapter-making-space" xreflabel="Chapter 3">
<title>Preparing a new partition</title>
<chapter id="chapter-getting-materials" xreflabel="Chapter 3">
<title>The materials: packages and patches</title>
<?dbhtml filename="chapter03.html" dir="chapter03"?>
<sect1 id="space-introduction">
<sect1 id="materials-introduction">
<title>Introduction</title>
<?dbhtml filename="introduction.html" dir="chapter03"?>
<para>In this chapter the partition which will host the LFS system is
prepared. We will create the partition itself, make a file system on it,
and mount it.</para>
<para>Below is a list of packages you need to download for building a basic
Linux system. The listed version numbers correspond to versions of the
software that are <emphasis>known</emphasis> to work, and this book is
based upon them. Unless you are an experienced LFS builder, we highly
recommend not to try out newer versions, as the build commands for one
version may not work with a newer version. Also, there is often a good
reason for not using the latest version due to known problems that haven't
been worked around yet.</para>
<para>All the URLs, when possible, refer to the project's page at
<ulink url="http://www.freshmeat.net/"/>. The Freshmeat
pages will give you easy access to the official download sites as well as
project websites, mailing lists, FAQs, changelogs and more.</para>
<para>We can't guarantee that these download locations are always available.
In case a download location has changed since this book was published, please
try to google for the package. Should you remain unsuccessful with this, you
can consult the book's errata page at <ulink url="&lfs-root;lfs/print/"/>
or, better yet, try one of the alternative means of downloading listed on
<ulink url="&lfs-root;lfs/packages.html"/>.</para>
<para>You'll need to store all the downloaded packages and patches somewhere
that is conveniently available throughout the entire build. You'll also need a
working directory in which to unpack the sources and build them. A scheme that
works well is to use <filename>$LFS/sources</filename> as the place to store
the tarballs and patches, <emphasis>and</emphasis> as a working directory.
This way everything you need will be located on the LFS partition and available
during all stages of the building process.</para>
<para>So you may want to execute, as <emphasis>root</emphasis>, the following
command before starting your download session:</para>
<screen><userinput>mkdir $LFS/sources</userinput></screen>
<para>And make this directory writable (and sticky) for your normal user -- as
you won't do the downloading as <emphasis>root</emphasis>, we guess:</para>
<screen><userinput>chmod a+wt $LFS/sources</userinput></screen>
<!--
<para>For your convenience the top of the list contains a link to a file
you can use with the <ulink url="http://wget.sunsite.dk">wget</ulink>
program. Using this file and the <command>wget</command> program will
make it easy to download all the files at once, rather than downloading each
and every individual file manually.</para>
-->
</sect1>
<sect1 id="space-creatingpartition">
<title>Creating a new partition</title>
<?dbhtml filename="creatingpartition.html" dir="chapter03"?>
<sect1 id="materials-packages">
<title>All the packages</title>
<?dbhtml filename="packages.html" dir="chapter03"?>
<para>In order to build our new Linux system, we will need some space:
an empty disk partition. If you don't have a free partition, and no room
on any of your hard disks to make one, then you could build LFS on the
same partition as the one on which your current distribution is installed.
This procedure is not recommended for your first LFS install, but if you
are short on disk space, and you feel brave, take a look at the hint at
<ulink url="&hints-root;lfs_next_to_existing_systems.txt"/>.</para>
<para>Download or otherwise obtain the following packages:</para>
<para>For a minimal system you will need a partition of around 1.2 GB.
This is enough to store all the source tarballs and compile all the packages.
But if you intend to use the LFS system as your primary Linux system, you
will probably want to install additional software, and will need more space
than this, probably around 2 or 3 GB.</para>
<literallayout>
Autoconf (&autoconf-version;) - &autoconf-size;:
<ulink url="http://freshmeat.net/projects/autoconf/"/>
<para>As we almost never have enough RAM in our box, it is a good idea to
use a small disk partition as swap space -- this space is used by the kernel
to store seldom-used data to make room in memory for more urgent stuff.
The swap partition for your LFS system can be the same one as for your host
system, so you won't have to create another if your host system already uses
a swap partition.</para>
Automake (&automake-version;) - &automake-size;:
<ulink url="http://freshmeat.net/projects/automake/"/>
<para>Start a disk partitioning program such as <command>cfdisk</command>
or <command>fdisk</command> with an argument naming the hard disk upon
which the new partition must be created -- for example
<filename>/dev/hda</filename> for the primary IDE disk. Create a Linux native
partition and a swap partition, if needed. Please refer to the man pages of
<command>cfdisk</command> or <command>fdisk</command> if you don't yet
know how to use the programs.</para>
Bash (&bash-version;) - &bash-size;:
<ulink url="http://freshmeat.net/projects/gnubash/"/>
<para>Remember the designation of your new partition -- something like
<filename>hda5</filename>. This book will refer to it as the LFS partition.
If you (now) also have a swap partition, remember its designation too. These
names will later be needed for the <filename>/etc/fstab</filename> file.</para>
Binutils (&binutils-version;) - &binutils-size;:
<ulink url="http://freshmeat.net/projects/binutils/"/>
Bison (&bison-version;) - &bison-size;:
<ulink url="http://freshmeat.net/projects/bison/"/>
Bzip2 (&bzip2-version;) - &bzip2-size;:
<ulink url="http://freshmeat.net/projects/bzip2/"/>
Coreutils (&coreutils-version;) - &coreutils-size;:
<ulink url="http://freshmeat.net/projects/coreutils/"/>
DejaGnu (&dejagnu-version;) - &dejagnu-size;:
<ulink url="http://freshmeat.net/projects/dejagnu/"/>
Diffutils (&diffutils-version;) - &diffutils-size;:
<ulink url="http://freshmeat.net/projects/diffutils/"/>
E2fsprogs (&e2fsprogs-version;) - &e2fsprogs-size;:
<ulink url="http://freshmeat.net/projects/e2fsprogs/"/>
Ed (&ed-version;) - &ed-size;:
<ulink url="http://freshmeat.net/projects/ed/"/>
Expect (&expect-version;) - &expect-size;:
<ulink url="http://freshmeat.net/projects/expect/"/>
File (&file-version;) - &file-size;: -- <emphasis>(see Note 1 below)</emphasis>
<ulink url="http://freshmeat.net/projects/file/"/>
Findutils (&findutils-version;) - &findutils-size;:
<ulink url="http://freshmeat.net/projects/findutils/"/>
Flex (&flex-version;) - &flex-size;:
<ulink url="ftp://ftp.gnu.org/gnu/non-gnu/flex/"/>
Gawk (&gawk-version;) - &gawk-size;:
<ulink url="http://freshmeat.net/projects/gnuawk/"/>
GCC-core (&gcc-version;) - &gcc-core-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
GCC-g++ (&gcc-version;) - &gcc-gpp-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
GCC-testsuite (&gcc-version;) - &gcc-testsuite-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
GCC-2 (&gcc-2953-version;) - &gcc-2953-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
Gettext (&gettext-version;) - &gettext-size;:
<ulink url="http://freshmeat.net/projects/gettext/"/>
Glibc (&glibc-version;) - &glibc-size;: -- <emphasis>(see Note 2 below)</emphasis>
<ulink url="http://freshmeat.net/projects/glibc/"/>
Grep (&grep-version;) - &grep-size;:
<ulink url="http://freshmeat.net/projects/grep/"/>
Groff (&groff-version;) - &groff-size;:
<ulink url="http://freshmeat.net/projects/groff/"/>
Grub (&grub-version;) - &grub-size;:
<ulink url="ftp://alpha.gnu.org/pub/gnu/grub/"/>
Gzip (&gzip-version;) - &gzip-size;:
<ulink url="ftp://alpha.gnu.org/gnu/gzip/"/>
Inetutils (&inetutils-version;) - &inetutils-size;:
<ulink url="http://freshmeat.net/projects/inetutils/"/>
Kbd (&kbd-version;) - &kbd-size;:
<ulink url="http://freshmeat.net/projects/kbd/"/>
Less (&less-version;) - &less-size;:
<ulink url="http://freshmeat.net/projects/less/"/>
LFS-Bootscripts (&bootscripts-version;) - &bootscripts-size;:
<ulink url="&http-down;lfs-bootscripts-&bootscripts-version;.tar.bz2"/>
Lfs-Utils (&lfs-utils-version;) - &lfs-utils-size;:
<ulink url="&lfs-root;~winkie/downloads/lfs-utils/"/>
Libtool (&libtool-version;) - &libtool-size;:
<ulink url="http://freshmeat.net/projects/libtool/"/>
Linux (&kernel-version;) - &kernel-size;:
<ulink url="http://freshmeat.net/projects/linux/"/>
M4 (&m4-version;) - &m4-size;:
<ulink url="http://freshmeat.net/projects/gnum4/"/>
Make (&make-version;) - &make-size;:
<ulink url="http://freshmeat.net/projects/gnumake/"/>
Make_devices (&makedev-version;) - &makedev-size;:
<ulink url="&lfs-root;~alex/make_devices-&makedev-version;.bz2"/>
Man (&man-version;) - &man-size;:
<ulink url="http://freshmeat.net/projects/man/"/>
Man-pages (&man-pages-version;) - &man-pages-size;:
<ulink url="http://freshmeat.net/projects/man-pages/"/>
Modutils (&modutils-version;) - &modutils-size;:
<ulink url="http://freshmeat.net/projects/modutils/"/>
Ncurses (&ncurses-version;) - &ncurses-size;:
<ulink url="http://freshmeat.net/projects/ncurses/"/>
Net-tools (&net-tools-version;) - &net-tools-size;:
<ulink url="http://freshmeat.net/projects/net-tools/"/>
Patch (&patch-version;) - &patch-size;:
<ulink url="http://freshmeat.net/projects/patch/"/>
Perl (&perl-version;) - &perl-size;:
<ulink url="http://freshmeat.net/projects/perl/"/>
Procinfo (&procinfo-version;) - &procinfo-size;:
<ulink url="http://freshmeat.net/projects/procinfo/"/>
Procps (&procps-version;) - &procps-size;:
<ulink url="http://freshmeat.net/projects/procps/"/>
Psmisc (&psmisc-version;) - &psmisc-size;:
<ulink url="http://freshmeat.net/projects/psmisc/"/>
Sed (&sed-version;) - &sed-size;:
<ulink url="http://freshmeat.net/projects/sed/"/>
Shadow (&shadow-version;) - &shadow-size;:
<ulink url="http://freshmeat.net/projects/shadow/"/>
Sysklogd (&sysklogd-version;) - &sysklogd-size;:
<ulink url="http://freshmeat.net/projects/sysklogd/"/>
Sysvinit (&sysvinit-version;) - &sysvinit-size;:
<ulink url="http://freshmeat.net/projects/sysvinit/"/>
Tar (&tar-version;) - &tar-size;:
<ulink url="ftp://alpha.gnu.org/gnu/tar/"/>
Tcl (&tcl-version;) - &tcl-size;:
<ulink url="http://freshmeat.net/projects/tcltk/"/>
Texinfo (&texinfo-version;) - &texinfo-size;:
<ulink url="http://freshmeat.net/projects/texinfo/"/>
Util-linux (&util-linux-version;) - &util-linux-size;:
<ulink url="http://freshmeat.net/projects/util-linux/"/>
Vim (&vim-version;) - &vim-size;:
<ulink url="http://freshmeat.net/projects/vim/"/>
Zlib (&zlib-version;) - &zlib-size;:
<ulink url="http://freshmeat.net/projects/zlib/"/>
Total size of these packages: &all-size-mb;
</literallayout>
<note><para>1) File (&file-version;) may not be available by the time you read
this. The site admins of the master download location are known to occasionally
remove old versions when new ones are released. Please refer to the
<xref linkend="ch-system-file"/> section for an alternate download
location.</para></note>
<note><para>2) As of this writing, the Glibc maintainers have decided in their
wisdom not to make available new release tarballs for download. The only way to
obtain the current Glibc release from pristine upstream sources is to pull it
from the Glibc CVS repository. The following commands will download the current
release and make a tarball from it:</para>
<screen><userinput>cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc \
&nbsp;&nbsp;&nbsp;&nbsp;export -d &glibc-dir; -D "2003-12-02 UTC" libc
tar jcvf &glibc-package; &glibc-dir;</userinput></screen>
<para>Alternatively, we've made our own tarball available which you can
download courtesy of the generous LFS mirror sites. Please refer to the
<xref linkend="ch-tools-glibc"/> section for the download links.</para></note>
</sect1>
<sect1 id="space-creatingfilesystem">
<title>Creating a file system on the new partition</title>
<?dbhtml filename="creatingfilesystem.html" dir="chapter03"?>
<sect1 id="materials-patches">
<title>Needed patches</title>
<?dbhtml filename="patches.html" dir="chapter03"?>
<para>Now that we have a blank partition, we can create a file system on it.
Most widely used in the Linux world is the second extended file system (ext2),
but with the high-capacity hard disks of today the so-called journaling
file systems are becoming increasingly popular. Here we will create an ext2
file system, but build instructions for other file systems can be found at
<ulink url="&blfs-root;view/stable/postlfs/filesystems.html"/>.</para>
<para>Besides all those packages, you'll also need several patches. These
correct tiny mistakes in the packages that should be fixed by the maintainer,
or just make some small modifications to bend things our way. You'll need the
following:</para>
<para>To create an ext2 file system on the LFS partition run the following:</para>
<literallayout>
Bash Patch - &bash-patch-size;:
<ulink url="&patches-root;&bash-patch;"/>
<screen><userinput>mke2fs /dev/xxx</userinput></screen>
Bison Attribute Patch - &bison-patch-size;:
<ulink url="&patches-root;&bison-patch;"/>
<para>Replace <filename>xxx</filename> with the name of the LFS partition
(something like <filename>hda5</filename>).</para>
Coreutils Hostname Patch - &coreutils-hostname-patch-size;:
<ulink url="&patches-root;&coreutils-hostname-patch;"/>
Coreutils Posixver Patch - &coreutils-posixver-patch-size;:
<ulink url="&patches-root;&coreutils-posixver-patch;"/>
Coreutils Uname Patch - &coreutils-uname-patch-size;:
<ulink url="&patches-root;&coreutils-uname-patch;"/>
<para>If you created a (new) swap partition you need to initialize it as a
swap partition too (also known as formatting, like you did above with
<command>mke2fs</command>) by running:</para>
Ed Mkstemp Patch - &ed-patch-size;:
<ulink url="&patches-root;&ed-patch;"/>
<screen><userinput>mkswap /dev/yyy</userinput></screen>
Expect Spawn Patch - &expect-patch-size;:
<ulink url="&patches-root;&expect-patch;"/>
<para>Replace <filename>yyy</filename> with the name of the swap
partition.</para>
GCC No-Fixincludes Patch - &gcc-nofixincludes-patch-size;:
<ulink url="&patches-root;&gcc-nofixincludes-patch;"/>
GCC Specs Patch - &gcc-specs-patch-size;:
<ulink url="&patches-root;&gcc-specs-patch;"/>
GCC-2 Patch - &gcc-2953-patch-size;:
<ulink url="&patches-root;&gcc-2953-patch;"/>
GCC-2 No-Fixincludes Patch - &gcc-2953-no-fixinc-patch-size;:
<ulink url="&patches-root;&gcc-2953-no-fixinc-patch;"/>
GCC-2 Return-Type Patch - &gcc-2953-returntype-fix-patch-size;:
<ulink url="&patches-root;&gcc-2953-returntype-fix-patch;"/>
Inetutils No-Server-Man-Pages Patch - &inetutils-no-server-man-pages-patch-size;:
<ulink url="&patches-root;&inetutils-no-server-man-pages-patch;"/>
Kbd More-Programs Patch - &kbd-patch-size;:
<ulink url="&patches-root;&kbd-patch;"/>
Man 80-Columns Patch - &man-80cols-patch-size;:
<ulink url="&patches-root;&man-80cols-patch;"/>
Net-tools Mii-Tool-Gcc33 Patch - &net-tools-mii-patch-size;:
<ulink url="&patches-root;&net-tools-mii-patch;"/>
Perl Libc Patch - &perl-libc-patch-size;:
<ulink url="&patches-root;&perl-libc-patch;"/>
</literallayout>
<para>In addition to the above required patches, there exist a number of
optional ones created by the LFS community. Most of these solve slight
problems, or enable some functionality that's not enabled by default.
Feel free to examine the patches database, located at <ulink
url="&lfs-root;patches/"/>, and pick any additional patches you wish to
use.</para>
</sect1>
<sect1 id="space-mounting">
<title>Mounting the new partition</title>
<?dbhtml filename="mounting.html" dir="chapter03"?>
<para>Now that we've created a file system, we want to be able to access
the partition. For that, we need to mount it, and have to choose a mount
point. In this book we assume that the file system is mounted under
<filename>/mnt/lfs</filename>, but it doesn't matter what directory
you choose.</para>
<para>Choose a mount point and assign it to the LFS environment variable
by running:</para>
<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
<para>Now create the mount point and mount the LFS file system by running:</para>
<screen><userinput>mkdir -p $LFS
mount /dev/xxx $LFS</userinput></screen>
<para>Replace <filename>xxx</filename> with the designation of the LFS
partition.</para>
<para>If you have decided to use multiple partitions for LFS (say one for
<filename>/</filename> and another for <filename>/usr</filename>), mount
them like this:</para>
<screen><userinput>mkdir -p $LFS
mount /dev/xxx $LFS
mkdir $LFS/usr
mount /dev/yyy $LFS/usr</userinput></screen>
<para>Of course, replace <filename>xxx</filename> and <filename>yyy</filename>
with the appropriate partition names.</para>
<para>You should also ensure that this new partition is not mounted with
permissions that are too restrictive (such as the nosuid, nodev or noatime
options). You can run the <command>mount</command> command without any
parameters to see with what options the LFS partition is mounted. If
you see nosuid, nodev or noatime, you will need to remount it.</para>
<para>Now that we've made ourselves a place to work in, we're ready to download
the packages.</para>
</sect1>
</chapter>

533
chapter04/chapter04.xml
View File

@ -1,333 +1,284 @@
<chapter id="chapter-getting-materials" xreflabel="Chapter 4">
<title>The materials: packages and patches</title>
<chapter id="chapter-preparation" xreflabel="Chapter 4">
<title>Last preparations</title>
<?dbhtml filename="chapter04.html" dir="chapter04"?>
<sect1 id="materials-introduction">
<title>Introduction</title>
<?dbhtml filename="introduction.html" dir="chapter04"?>
<sect1 id="prepare-aboutlfs">
<title>About $LFS</title>
<?dbhtml filename="aboutlfs.html" dir="chapter04"?>
<para>Below is a list of packages you need to download for building a basic
Linux system. The listed version numbers correspond to versions of the
software that are <emphasis>known</emphasis> to work, and this book is
based upon them. Unless you are an experienced LFS builder, we highly
recommend not to try out newer versions, as the build commands for one
version may not work with a newer version. Also, there is often a good
reason for not using the latest version due to known problems that haven't
been worked around yet.</para>
<para>Throughout this book the environment variable LFS will be used several
times. It is paramount that this variable is always defined. It should be set
to the mount point you chose for your LFS partition. Check that your LFS
variable is set up properly with:</para>
<para>All the URLs, when possible, refer to the project's page at
<ulink url="http://www.freshmeat.net/"/>. The Freshmeat
pages will give you easy access to the official download sites as well as
project websites, mailing lists, FAQs, changelogs and more.</para>
<screen><userinput>echo $LFS</userinput></screen>
<para>We can't guarantee that these download locations are always available.
In case a download location has changed since this book was published, please
try to google for the package. Should you remain unsuccessful with this, you
can consult the book's errata page at <ulink url="&lfs-root;lfs/print/"/>
or, better yet, try one of the alternative means of downloading listed on
<ulink url="&lfs-root;lfs/packages.html"/>.</para>
<para>Make sure the output shows the path to your LFS partition's mount
point, which is <filename class="directory">/mnt/lfs</filename> if you
followed our example. If the output is wrong, you can always set the variable
with:</para>
<para>You'll need to store all the downloaded packages and patches somewhere
that is conveniently available throughout the entire build. You'll also need a
working directory in which to unpack the sources and build them. A scheme that
works well is to use <filename>$LFS/sources</filename> as the place to store
the tarballs and patches, <emphasis>and</emphasis> as a working directory.
This way everything you need will be located on the LFS partition and available
during all stages of the building process.</para>
<screen><userinput>export LFS=/mnt/lfs</userinput></screen>
<para>So you may want to execute, as <emphasis>root</emphasis>, the following
command before starting your download session:</para>
<screen><userinput>mkdir $LFS/sources</userinput></screen>
<para>And make this directory writable (and sticky) for your normal user -- as
you won't do the downloading as <emphasis>root</emphasis>, we guess:</para>
<screen><userinput>chmod a+wt $LFS/sources</userinput></screen>
<!--
<para>For your convenience the top of the list contains a link to a file
you can use with the <ulink url="http://wget.sunsite.dk">wget</ulink>
program. Using this file and the <command>wget</command> program will
make it easy to download all the files at once, rather than downloading each
and every individual file manually.</para>
-->
<para>Having this variable set means that if you are told to run a command like
<userinput>mkdir $LFS/tools</userinput>, you can type it literally. Your shell
will replace "$LFS" with "/mnt/lfs" (or whatever you set the variable to) when
it processes the command line.</para>
</sect1>
<sect1 id="materials-packages">
<title>All the packages</title>
<?dbhtml filename="packages.html" dir="chapter04"?>
<sect1 id="prepare-creatingtoolsdir">
<title>Creating the $LFS/tools directory</title>
<?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?>
<para>Download or otherwise obtain the following packages:</para>
<para>All programs compiled in this chapter will be installed under <filename
class="directory">$LFS/tools</filename> to keep them separate from the
programs compiled in the next chapter. The programs compiled here are only
temporary tools and won't be a part of the final LFS system and by keeping them
in a separate directory, we can later easily throw them away.</para>
<literallayout>
Autoconf (&autoconf-version;) - &autoconf-size;:
<ulink url="http://freshmeat.net/projects/autoconf/"/>
<para>Later on you might wish to search through the binaries of your system to
see what files they make use of or link against. To make this searching easier
you may want to choose a unique name for the directory in which the temporary
tools are stored. Instead of the simple "tools" you could use something like
"tools-for-lfs". However, you'll need to be careful to adjust all references to
"tools" throughout the book -- including those in any patches, notably the
GCC Specs Patch.</para>
Automake (&automake-version;) - &automake-size;:
<ulink url="http://freshmeat.net/projects/automake/"/>
<para>Create the required directory by running the following:</para>
Bash (&bash-version;) - &bash-size;:
<ulink url="http://freshmeat.net/projects/gnubash/"/>
<screen><userinput>mkdir $LFS/tools</userinput></screen>
Binutils (&binutils-version;) - &binutils-size;:
<ulink url="http://freshmeat.net/projects/binutils/"/>
<para>The next step is to create a <filename>/tools</filename> symlink on
your host system. It will point to the directory we just created on the LFS
partition:</para>
Bison (&bison-version;) - &bison-size;:
<ulink url="http://freshmeat.net/projects/bison/"/>
<screen><userinput>ln -s $LFS/tools /</userinput></screen>
Bzip2 (&bzip2-version;) - &bzip2-size;:
<ulink url="http://freshmeat.net/projects/bzip2/"/>
<note><para>The above command is correct. The <command>ln</command> command
has a few syntactic variations, so be sure to check the info page before
reporting what you may think is an error.</para></note>
Coreutils (&coreutils-version;) - &coreutils-size;:
<ulink url="http://freshmeat.net/projects/coreutils/"/>
DejaGnu (&dejagnu-version;) - &dejagnu-size;:
<ulink url="http://freshmeat.net/projects/dejagnu/"/>
Diffutils (&diffutils-version;) - &diffutils-size;:
<ulink url="http://freshmeat.net/projects/diffutils/"/>
E2fsprogs (&e2fsprogs-version;) - &e2fsprogs-size;:
<ulink url="http://freshmeat.net/projects/e2fsprogs/"/>
Ed (&ed-version;) - &ed-size;:
<ulink url="http://freshmeat.net/projects/ed/"/>
Expect (&expect-version;) - &expect-size;:
<ulink url="http://freshmeat.net/projects/expect/"/>
File (&file-version;) - &file-size;: -- <emphasis>(see Note 1 below)</emphasis>
<ulink url="http://freshmeat.net/projects/file/"/>
Findutils (&findutils-version;) - &findutils-size;:
<ulink url="http://freshmeat.net/projects/findutils/"/>
Flex (&flex-version;) - &flex-size;:
<ulink url="ftp://ftp.gnu.org/gnu/non-gnu/flex/"/>
Gawk (&gawk-version;) - &gawk-size;:
<ulink url="http://freshmeat.net/projects/gnuawk/"/>
GCC (&gcc-2953-version;) - &gcc-2953-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
GCC-core (&gcc-version;) - &gcc-core-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
GCC-g++ (&gcc-version;) - &gcc-gpp-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
GCC-testsuite (&gcc-version;) - &gcc-testsuite-size;:
<ulink url="http://freshmeat.net/projects/gcc/"/>
Gettext (&gettext-version;) - &gettext-size;:
<ulink url="http://freshmeat.net/projects/gettext/"/>
Glibc (&glibc-version;) - &glibc-size;: -- <emphasis>(see Note 2 below)</emphasis>
<ulink url="http://freshmeat.net/projects/glibc/"/>
Grep (&grep-version;) - &grep-size;:
<ulink url="http://freshmeat.net/projects/grep/"/>
Groff (&groff-version;) - &groff-size;:
<ulink url="http://freshmeat.net/projects/groff/"/>
Grub (&grub-version;) - &grub-size;:
<ulink url="ftp://alpha.gnu.org/pub/gnu/grub/"/>
Gzip (&gzip-version;) - &gzip-size;:
<ulink url="ftp://alpha.gnu.org/gnu/gzip/"/>
Inetutils (&inetutils-version;) - &inetutils-size;:
<ulink url="http://freshmeat.net/projects/inetutils/"/>
Kbd (&kbd-version;) - &kbd-size;:
<ulink url="http://freshmeat.net/projects/kbd/"/>
Less (&less-version;) - &less-size;:
<ulink url="http://freshmeat.net/projects/less/"/>
LFS-Bootscripts (&bootscripts-version;) - &bootscripts-size;:
<ulink url="&http-down;lfs-bootscripts-&bootscripts-version;.tar.bz2"/>
Lfs-Utils (&lfs-utils-version;) - &lfs-utils-size;:
<ulink url="&lfs-root;~winkie/downloads/lfs-utils/"/>
Libtool (&libtool-version;) - &libtool-size;:
<ulink url="http://freshmeat.net/projects/libtool/"/>
Linux (&kernel-version;) - &kernel-size;:
<ulink url="http://freshmeat.net/projects/linux/"/>
M4 (&m4-version;) - &m4-size;:
<ulink url="http://freshmeat.net/projects/gnum4/"/>
Make (&make-version;) - &make-size;:
<ulink url="http://freshmeat.net/projects/gnumake/"/>
Make_devices (&makedev-version;) - &makedev-size;:
<ulink url="&lfs-root;~alex/make_devices-&makedev-version;.bz2"/>
Man (&man-version;) - &man-size;:
<ulink url="http://freshmeat.net/projects/man/"/>
Man-pages (&man-pages-version;) - &man-pages-size;:
<ulink url="http://freshmeat.net/projects/man-pages/"/>
Modutils (&modutils-version;) - &modutils-size;:
<ulink url="http://freshmeat.net/projects/modutils/"/>
Ncurses (&ncurses-version;) - &ncurses-size;:
<ulink url="http://freshmeat.net/projects/ncurses/"/>
Net-tools (&net-tools-version;) - &net-tools-size;:
<ulink url="http://freshmeat.net/projects/net-tools/"/>
Patch (&patch-version;) - &patch-size;:
<ulink url="http://freshmeat.net/projects/patch/"/>
Perl (&perl-version;) - &perl-size;:
<ulink url="http://freshmeat.net/projects/perl/"/>
Procinfo (&procinfo-version;) - &procinfo-size;:
<ulink url="http://freshmeat.net/projects/procinfo/"/>
Procps (&procps-version;) - &procps-size;:
<ulink url="http://freshmeat.net/projects/procps/"/>
Psmisc (&psmisc-version;) - &psmisc-size;:
<ulink url="http://freshmeat.net/projects/psmisc/"/>
Sed (&sed-version;) - &sed-size;:
<ulink url="http://freshmeat.net/projects/sed/"/>
Shadow (&shadow-version;) - &shadow-size;:
<ulink url="http://freshmeat.net/projects/shadow/"/>
Sysklogd (&sysklogd-version;) - &sysklogd-size;:
<ulink url="http://freshmeat.net/projects/sysklogd/"/>
Sysvinit (&sysvinit-version;) - &sysvinit-size;:
<ulink url="http://freshmeat.net/projects/sysvinit/"/>
Tar (&tar-version;) - &tar-size;:
<ulink url="ftp://alpha.gnu.org/gnu/tar/"/>
Tcl (&tcl-version;) - &tcl-size;:
<ulink url="http://freshmeat.net/projects/tcltk/"/>
Texinfo (&texinfo-version;) - &texinfo-size;:
<ulink url="http://freshmeat.net/projects/texinfo/"/>
Util-linux (&util-linux-version;) - &util-linux-size;:
<ulink url="http://freshmeat.net/projects/util-linux/"/>
Vim (&vim-version;) - &vim-size;:
<ulink url="http://freshmeat.net/projects/vim/"/>
Zlib (&zlib-version;) - &zlib-size;:
<ulink url="http://freshmeat.net/projects/zlib/"/>
Total size of these packages: &all-size-mb;
</literallayout>
<note><para>1) File (&file-version;) may not be available by the time you read
this. The site admins of the master download location are known to occasionally
remove old versions when new ones are released. Please refer to the
<xref linkend="ch-system-file"/> section for an alternate download
location.</para></note>
<note><para>2) As of this writing, the Glibc maintainers have decided in their
wisdom not to make available new release tarballs for download. The only way to
obtain the current Glibc release from pristine upstream sources is to pull it
from the Glibc CVS repository. The following commands will download the current
release and make a tarball from it:</para>
<screen><userinput>cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc \
&nbsp;&nbsp;&nbsp;&nbsp;export -d &glibc-dir; -D "2003-12-02 UTC" libc
tar jcvf &glibc-package; &glibc-dir;</userinput></screen>
<para>Alternatively, we've made our own tarball available which you can
download courtesy of the generous LFS mirror sites. Please refer to the
<xref linkend="ch-tools-glibc"/> section for the download links.</para></note>
<para>The created symlink enables us to compile our toolchain so that it always
refers to <filename>/tools</filename>, meaning that the compiler, assembler
and linker will work both in this chapter (when we are still using some tools
from the host) <emphasis>and</emphasis> in the next (when we are chrooted to
the LFS partition).</para>
</sect1>
<sect1 id="materials-patches">
<title>Needed patches</title>
<?dbhtml filename="patches.html" dir="chapter04"?>
<sect1 id="prepar-addinguser">
<title>Adding the user lfs</title>
<?dbhtml filename="addinguser.html" dir="chapter05"?>
<para>Besides all those packages, you'll also need several patches. These
correct tiny mistakes in the packages that should be fixed by the maintainer,
or just make some small modifications to bend things our way. You'll need the
following:</para>
<para>When logged in as <emphasis>root</emphasis>, making a single mistake
can damage or even wreck your system. Therefore we recommend that you
build the packages in this chapter as an unprivileged user. You could
of course use your own user name, but to make it easier to set up a clean
work environment we'll create a new user <emphasis>lfs</emphasis> and
use this one during the installation process. As <emphasis>root</emphasis>,
issue the following command to add the new user:</para>
<literallayout>
Bash Patch - &bash-patch-size;:
<ulink url="&patches-root;&bash-patch;"/>
<screen><userinput>useradd -s /bin/bash -m -k /dev/null lfs</userinput></screen>
Bison Attribute Patch - &bison-patch-size;:
<ulink url="&patches-root;&bison-patch;"/>
<para>The meaning of the switches:</para>
Coreutils Hostname Patch - &coreutils-hostname-patch-size;:
<ulink url="&patches-root;&coreutils-hostname-patch;"/>
<itemizedlist>
<listitem><para><userinput>-s /bin/bash</userinput>: This makes
<userinput>bash</userinput> the default shell for user
<emphasis>lfs</emphasis>.</para></listitem>
Coreutils Posixver Patch - &coreutils-posixver-patch-size;:
<ulink url="&patches-root;&coreutils-posixver-patch;"/>
<listitem><para><userinput>-m -k /dev/null</userinput>: These create a home
directory for <emphasis>lfs</emphasis>, while preventing the files from a
possible <filename>/etc/skel</filename> being copied into it.</para></listitem>
</itemizedlist>
Coreutils Uname Patch - &coreutils-uname-patch-size;:
<ulink url="&patches-root;&coreutils-uname-patch;"/>
<para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give
this new user a password:</para>
Ed Mkstemp Patch - &ed-patch-size;:
<ulink url="&patches-root;&ed-patch;"/>
<screen><userinput>passwd lfs</userinput></screen>
Expect Spawn Patch - &expect-patch-size;:
<ulink url="&patches-root;&expect-patch;"/>
<para>Now grant this new user <emphasis>lfs</emphasis> full access to
<filename class="directory">$LFS/tools</filename> by giving it ownership
of the directory:</para>
GCC No-Fixincludes Patch - &gcc-nofixincludes-patch-size;:
<ulink url="&patches-root;&gcc-nofixincludes-patch;"/>
<screen><userinput>chown lfs $LFS/tools</userinput></screen>
GCC Specs Patch - &gcc-specs-patch-size;:
<ulink url="&patches-root;&gcc-specs-patch;"/>
<para>If you made a separate working directory as suggested, give user
<emphasis>lfs</emphasis> ownership of this directory too:</para>
GCC-2 Patch - &gcc-2953-patch-size;:
<ulink url="&patches-root;&gcc-2953-patch;"/>
<screen><userinput>chown lfs $LFS/sources</userinput></screen>
GCC-2 No-Fixincludes Patch - &gcc-2953-no-fixinc-patch-size;:
<ulink url="&patches-root;&gcc-2953-no-fixinc-patch;"/>
<para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a
virtual console, through a display manager, or with the following substitute
user command:</para>
GCC-2 Return-Type Patch - &gcc-2953-returntype-fix-patch-size;:
<ulink url="&patches-root;&gcc-2953-returntype-fix-patch;"/>
<screen><userinput>su - lfs</userinput></screen>
Inetutils No-Server-Man-Pages Patch - &inetutils-no-server-man-pages-patch-size;:
<ulink url="&patches-root;&inetutils-no-server-man-pages-patch;"/>
Kbd More-Programs Patch - &kbd-patch-size;:
<ulink url="&patches-root;&kbd-patch;"/>
Man 80-Columns Patch - &man-80cols-patch-size;:
<ulink url="&patches-root;&man-80cols-patch;"/>
Net-tools Mii-Tool-Gcc33 Patch - &net-tools-mii-patch-size;:
<ulink url="&patches-root;&net-tools-mii-patch;"/>
Perl Libc Patch - &perl-libc-patch-size;:
<ulink url="&patches-root;&perl-libc-patch;"/>
</literallayout>
<para>In addition to the above required patches, there exist a number of
optional ones created by the LFS community. Most of these solve slight
problems, or enable some functionality that's not enabled by default.
Feel free to examine the patches database, located at <ulink
url="&lfs-root;patches/"/>, and pick any additional patches you wish to
use.</para>
<para>The "<command>-</command>" instructs <command>su</command> to start a
<emphasis>login</emphasis> shell.</para>
</sect1>
<sect1 id="prepare-settingenvironment">
<title>Setting up the environment</title>
<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
<para>We're going to set up a good working environment by creating two new
startup files for the <command>bash</command> shell. While logged in as
user <emphasis>lfs</emphasis>, issue the following command to create a new
<filename>.bash_profile</filename>:</para>
<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"</userinput>
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
<userinput>EOF</userinput></screen>
<para>Normally, when you log on as user <emphasis>lfs</emphasis>,
the initial shell is a <emphasis>login</emphasis> shell which reads the
<filename>/etc/profile</filename> of your host (probably containing some
settings of environment variables) and then <filename>.bash_profile</filename>.
The <command>exec env -i ... /bin/bash</command> command in the latter file
replaces the running shell with a new one with a completely empty environment,
except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
potentially hazardous environment variables from the host system leak into our
build environment. The technique used here is a little strange, but it achieves
the goal of enforcing a clean environment.</para>
<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
which doesn't read the <filename>/etc/profile</filename> or
<filename>.bash_profile</filename> files, but reads the
<filename>.bashrc</filename> file instead. Create this latter file now:</para>
<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"</userinput>
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL PATH
<userinput>EOF</userinput></screen>
<para>The <command>set +h</command> command turns off
<command>bash</command>'s hash function. Normally hashing is a useful
feature: <command>bash</command> uses a hash table to remember the
full pathnames of executable files to avoid searching the PATH time and time
again to find the same executable. However, we'd like the new tools to be
used as soon as they are installed. By switching off the hash function, our
"interactive" commands (<command>make</command>,
<command>patch</command>, <command>sed</command>,
<command>cp</command> and so forth) will always use
the newest available version during the build process.</para>
<para>Setting the user file-creation mask to 022 ensures that newly created
files and directories are only writable for their owner, but readable and
executable for anyone.</para>
<para>The LFS variable should of course be set to the mount point you
chose.</para>
<para>The LC_ALL variable controls the localization of certain programs,
making their messages follow the conventions of a specified country. If your
host system uses a version of Glibc older than 2.2.4,
having LC_ALL set to something other than "POSIX" or "C" during this chapter
may cause trouble if you exit the chroot environment and wish to return later.
By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that
everything will work as expected in the chroot environment.</para>
<para>We prepend <filename>/tools/bin</filename> to the standard PATH so
that, as we move along through this chapter, the tools we build will get used
during the rest of the building process.</para>
<para>Finally, to have our environment fully prepared for building the
temporary tools, source the just-created profile:</para>
<screen><userinput>source ~/.bash_profile</userinput></screen>
</sect1>
<sect1 id="prepare-aboutsbus">
<title>About SBUs</title>
<?dbhtml filename="aboutsbus.html" dir="chapter04"?>
<para>Most people would like to know beforehand how long it approximately
takes to compile and install each package. But "Linux from Scratch" is built
on so many different systems, it is not possible to give actual times that are
anywhere near accurate: the biggest package (Glibc) won't take more than
twenty minutes on the fastest systems, but will take something like three days
on the slowest -- no kidding. So instead of giving actual times, we've come up
with the idea of using the <emphasis>Static Binutils Unit</emphasis>
(abbreviated to <emphasis>SBU</emphasis>).</para>
<para>It works like this: the first package you compile in this book is the
statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it
takes to compile this package is what we call the "Static Binutils Unit" or
"SBU". All other compile times will be expressed relative to this time.</para>
<para>For example, the time it takes to build the static version of GCC is
&gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes
to compile and install the static Binutils, then you know it will take
approximately 45 minutes to build the static GCC. Fortunately, most build times
are much shorter than the one of Binutils.</para>
<para>Note that if the system compiler on your host is GCC-2 based, the SBUs
listed may end up being somewhat understated. This is because the SBU is based
on the very first package, compiled with the old GCC, while the rest of the
system is compiled with the newer GCC-&gcc-version; which is known to be
approximately 30% slower.</para>
<para>Also note that SBUs don't work well for SMP-based machines. But if you're
so lucky as to have multiple processors, chances are that your system is so fast
that you won't mind.</para>
<para>If you wish to see actual timings for specific machines, have a look at
<ulink url="&lfs-root;~bdubbs/"/>.</para>
</sect1>
<sect1 id="prepare-abouttestsuites">
<title>About the test suites</title>
<?dbhtml filename="abouttestsuites.html" dir="chapter04"?>
<para>Most packages provide a test suite. Running the test suite for a newly
built package is generally a good idea, as it can provide a nice sanity check
that everything compiled correctly. A test suite that passes its set of checks
usually proves that the package is functioning as the developer intended. It
does not, however, guarantee that the package is totally bug free.</para>
<para>Some test suites are more important than others. For example, the test
suites for the core toolchain packages -- GCC, Binutils, and Glibc -- are of
the utmost importance due to their central role in a properly functioning
system. But be warned, the test suites for GCC and Glibc can take a very long
time to complete, especially on slower hardware.</para>
<note><para>Experience has shown us 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 weird and inexplicable failures. Not only
that, the tools built in <xref linkend="chapter-temporary-tools"/> are
temporary and eventually discarded. For the average reader of this book we
recommend <emphasis>not</emphasis> to run the test suites in <xref
linkend="chapter-temporary-tools"/>. The instructions for running those test
suites are still provided for the benefit of testers and developers, but they
are strictly optional for everyone else.</para></note>
<para>A common problem when running the test suites for Binutils and GCC is
running out of pseudo terminals (PTYs for short). The symptom is a very high
number of failing tests. This can happen for several reasons, but the most
likely cause is that the host system doesn't have the
<emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in
more detail later on in <xref linkend="chapter-temporary-tools"/>.</para>
<para>Sometimes package test suites will give false failures. You can
consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
failures are normal. This applies to all tests throughout the book.</para>
</sect1>
</chapter>

208
chapter05/chapter05.xml
View File

@ -23,9 +23,9 @@ Since the packages compiled here are merely temporary, we don't want
them to pollute the soon-to-be LFS system.</para>
<para>Before issuing the build instructions for a package you are expected to
have already unpacked it as user <emphasis>lfs</emphasis> (explained shortly),
and to have performed a <userinput>cd</userinput> into the created directory.
The build instructions assume that you are using the <command>bash</command>
have already unpacked it as user <emphasis>lfs</emphasis>, and to have
performed a <userinput>cd</userinput> into the created directory. The build
instructions assume that you are using the <command>bash</command>
shell.</para>
<para>Several of the packages are patched before compilation, but only when
@ -50,21 +50,12 @@ reinstalled further on. Only for three packages you will need to keep the
source and build directories around for a while, so their contents can be used
by later commands. Do not miss the reminders.</para>
<para>Now first check that your LFS environment variable is set up
properly:</para>
<screen><userinput>echo $LFS</userinput></screen>
<para>Make sure the output shows the path to your LFS partition's mount
point, which is <filename class="directory">/mnt/lfs</filename> if you
followed our example.</para>
</sect1>
<sect1 id="ch-tools-toolchaintechnotes">
<title>Toolchain technical notes</title>
<?dbhtml filename="toolchaintechnotes.html" dir="chapter05"?>
<sect1 id="tools-technicalnotes">
<title>Technical notes</title>
<?dbhtml filename="technicalnotes.html" dir="chapter05"?>
<para>This section attempts to explain some of the rationale and technical
details behind the overall build method. It's not essential that you understand
@ -217,8 +208,12 @@ we mentioned above. Once this Glibc is installed into
the toolchain defaults, then proceed for real in building the rest of the
target LFS system.</para>
<sect2>
</sect1>
<sect1 id="tools-aboutlinking">
<title>Notes on static linking</title>
<?dbhtml filename="aboutlinking.html" dir="chapter05"?>
<para>Most programs have to perform, beside their specific task, many rather
common and sometimes trivial operations. These include allocating memory,
@ -257,179 +252,6 @@ independently of the host system. However, it's worth noting that an overall
successful LFS build can still be achieved when the first two packages are
built dynamically.</para>
</sect2>
</sect1>
<sect1 id="ch-tools-creatingtoolsdir">
<title>Creating the $LFS/tools directory</title>
<?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?>
<para>All programs compiled in this chapter will be installed under <filename
class="directory">$LFS/tools</filename> to keep them separate from the
programs compiled in the next chapter. The programs compiled here are only
temporary tools and won't be a part of the final LFS system and by keeping them
in a separate directory, we can later easily throw them away.</para>
<para>Later on you might wish to search through the binaries of your system to
see what files they make use of or link against. To make this searching easier
you may want to choose a unique name for the directory in which the temporary
tools are stored. Instead of the simple "tools" you could use something like
"tools-for-lfs". However, you'll need to be careful to adjust all references to
"tools" throughout the book -- including those in any patches, notably the
GCC Specs Patch.</para>
<para>Create the required directory by running the following:</para>
<screen><userinput>mkdir $LFS/tools</userinput></screen>
<para>The next step is to create a <filename>/tools</filename> symlink on
your host system. It will point to the directory we just created on the LFS
partition:</para>
<screen><userinput>ln -s $LFS/tools /</userinput></screen>
<note><para>The above command is correct. The <command>ln</command> command
has a few syntactic variations, so be sure to check the info page before
reporting what you may think is an error.</para></note>
<para>The created symlink enables us to compile our toolchain so that it always
refers to <filename>/tools</filename>, meaning that the compiler, assembler
and linker will work both in this chapter (when we are still using some tools
from the host) <emphasis>and</emphasis> in the next (when we are chrooted to
the LFS partition).</para>
</sect1>
<sect1 id="ch-tools-addinguser">
<title>Adding the user lfs</title>
<?dbhtml filename="addinguser.html" dir="chapter05"?>
<para>When logged in as <emphasis>root</emphasis>, making a single mistake
can damage or even wreck your system. Therefore we recommend that you
build the packages in this chapter as an unprivileged user. You could
of course use your own user name, but to make it easier to set up a clean
work environment we'll create a new user <emphasis>lfs</emphasis> and
use this one during the installation process. As <emphasis>root</emphasis>,
issue the following command to add the new user:</para>
<screen><userinput>useradd -s /bin/bash -m -k /dev/null lfs</userinput></screen>
<para>The meaning of the switches:</para>
<itemizedlist>
<listitem><para><userinput>-s /bin/bash</userinput>: This makes
<userinput>bash</userinput> the default shell for user
<emphasis>lfs</emphasis>.</para></listitem>
<listitem><para><userinput>-m -k /dev/null</userinput>: These create a home
directory for <emphasis>lfs</emphasis>, while preventing the files from a
possible <filename>/etc/skel</filename> being copied into it.</para></listitem>
</itemizedlist>
<para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give
this new user a password:</para>
<screen><userinput>passwd lfs</userinput></screen>
<para>Now grant this new user <emphasis>lfs</emphasis> full access to
<filename class="directory">$LFS/tools</filename> by giving it ownership
of the directory:</para>
<screen><userinput>chown lfs $LFS/tools</userinput></screen>
<para>If you made a separate working directory as suggested, give user
<emphasis>lfs</emphasis> ownership of this directory too:</para>
<screen><userinput>chown lfs $LFS/sources</userinput></screen>
<para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a
virtual console, through a display manager, or with the following substitute
user command:</para>
<screen><userinput>su - lfs</userinput></screen>
<para>The "<command>-</command>" instructs <command>su</command> to start a
<emphasis>login</emphasis> shell.</para>
</sect1>
<sect1 id="ch-tools-settingenviron">
<title>Setting up the environment</title>
<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
<para>We're going to set up a good working environment by creating two new
startup files for the <command>bash</command> shell. While logged in as
user <emphasis>lfs</emphasis>, issue the following command to create a new
<filename>.bash_profile</filename>:</para>
<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"</userinput>
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
<userinput>EOF</userinput></screen>
<para>Normally, when you log on as user <emphasis>lfs</emphasis>,
the initial shell is a <emphasis>login</emphasis> shell which reads the
<filename>/etc/profile</filename> of your host (probably containing some
settings of environment variables) and then <filename>.bash_profile</filename>.
The <command>exec env -i ... /bin/bash</command> command in the latter file
replaces the running shell with a new one with a completely empty environment,
except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
potentially hazardous environment variables from the host system leak into our
build environment. The technique used here is a little strange, but it achieves
the goal of enforcing a clean environment.</para>
<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
which doesn't read the <filename>/etc/profile</filename> or
<filename>.bash_profile</filename> files, but reads the
<filename>.bashrc</filename> file instead. Create this latter file now:</para>
<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"</userinput>
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL PATH
<userinput>EOF</userinput></screen>
<para>The <command>set +h</command> command turns off
<command>bash</command>'s hash function. Normally hashing is a useful
feature: <command>bash</command> uses a hash table to remember the
full pathnames of executable files to avoid searching the PATH time and time
again to find the same executable. However, we'd like the new tools to be
used as soon as they are installed. By switching off the hash function, our
"interactive" commands (<command>make</command>,
<command>patch</command>, <command>sed</command>,
<command>cp</command> and so forth) will always use
the newest available version during the build process.</para>
<para>Setting the user file-creation mask to 022 ensures that newly created
files and directories are only writable for their owner, but readable and
executable for anyone.</para>
<para>The LFS variable should of course be set to the mount point you
chose.</para>
<para>The LC_ALL variable controls the localization of certain programs,
making their messages follow the conventions of a specified country. If your
host system uses a version of Glibc older than 2.2.4,
having LC_ALL set to something other than "POSIX" or "C" during this chapter
may cause trouble if you exit the chroot environment and wish to return later.
By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that
everything will work as expected in the chroot environment.</para>
<para>We prepend <filename>/tools/bin</filename> to the standard PATH so
that, as we move along through this chapter, the tools we build will get used
during the rest of the building process.</para>
<para>Finally, to have our environment fully prepared for building the
temporary tools, source the just-created profile:</para>
<screen><userinput>source ~/.bash_profile</userinput></screen>
</sect1>
@ -490,7 +312,7 @@ made.</para>
linker is something other than <filename>ld-linux.so.2</filename>, you
<emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
name of your platform's dynamic linker in the above commands. Refer back to
<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
<xref linkend="tools-technicalnotes"/> if necessary.</para></important>
<para>Lastly, there is a possibility that some include files from the host
system have found their way into GCC's private include dir. This can happen
@ -531,9 +353,9 @@ First, redo the sanity check using <command>gcc</command> instead of
is correct. You can check this by running <userinput>echo $PATH</userinput> and
verifying that <filename class="directory">/tools/bin</filename> is at the head
of the list. If the PATH is wrong it could mean you're not logged in as user
<emphasis>lfs</emphasis> or something went wrong back in
<xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with
the specs file amendment above. In this case redo the specs file amendment
<emphasis>lfs</emphasis> or something went wrong back in <xref
linkend="prepare-settingenvironment"/>. Third, something may have gone wrong
with the specs file amendment above. In this case redo the specs file amendment
ensuring to cut-and-paste the commands as was recommended.</para>
<para>Once you are satisfied that all is well, clean up the test files:</para>

2
chapter06/chapter06.xml
View File

@ -424,7 +424,7 @@ intended change was actually made.</para>
linker is something other than <filename>ld-linux.so.2</filename>, you
<emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
name of your platform's dynamic linker in the above commands. Refer back to
<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
<xref linkend="tools-technicalnotes"/> if necessary.</para></important>
<!-- HACK - Force some whitespace to appease tidy -->
<literallayout></literallayout>

11
entities/book-structure.xml
View File

@ -10,28 +10,19 @@
<!ENTITY c1-how SYSTEM "../chapter01/how.xml">
<!ENTITY c1-changelog SYSTEM "../chapter01/changelog.xml">
<!ENTITY c1-resources SYSTEM "../chapter01/contactinfo.xml">
<!ENTITY c1-askforhelp SYSTEM "../chapter01/askforhelp.xml">
<!ENTITY chapter02 SYSTEM "../chapter02/chapter02.xml">
<!ENTITY c2-aboutlfs SYSTEM "../chapter02/aboutlfs.xml">
<!ENTITY c2-aboutsbus SYSTEM "../chapter02/aboutsbus.xml">
<!ENTITY c2-abouttestsuites SYSTEM "../chapter02/abouttestsuites.xml">
<!ENTITY c2-askforhelp SYSTEM "../chapter02/askforhelp.xml">
<!ENTITY chapter03 SYSTEM "../chapter03/chapter03.xml">
<!ENTITY c3-introduction SYSTEM "../chapter03/introduction.xml">
<!ENTITY c3-creatingpart SYSTEM "../chapter03/creatingpart.xml">
<!ENTITY c3-creatingfs SYSTEM "../chapter03/creatingfs.xml">
<!ENTITY c3-mounting SYSTEM "../chapter03/mounting.xml">
<!ENTITY chapter04 SYSTEM "../chapter04/chapter04.xml">
<!ENTITY chapter05 SYSTEM "../chapter05/chapter05.xml">
<!ENTITY chapter06 SYSTEM "../chapter06/chapter06.xml">
<!ENTITY c6-aboutdebug SYSTEM "../chapter06/aboutdebug.xml">
<!ENTITY chapter07 SYSTEM "../chapter07/chapter07.xml">
<!ENTITY c7-introduction SYSTEM "../chapter07/introduction.xml">
<!ENTITY c7-usage SYSTEM "../chapter07/usage.xml">
<!ENTITY c7-setclock SYSTEM "../chapter07/setclock.xml">
<!ENTITY c7-loadkeys SYSTEM "../chapter07/loadkeys.xml">

35
preface/organization.xml
View File

@ -4,37 +4,34 @@
<para>This book is divided into the following four parts:</para>
<sect2>
<title>Part I - Introduction</title>
<itemizedlist>
<para>Part I explains a few important things on how to proceed with the
installation, and gives meta information about the book (version, changelog,
acknowledgments, associated mailing lists, and so on).</para>
</sect2>
<sect2>
<title>Part II - Preparing for the build</title>
<listitem>
<para>Part I explains in some detail how the LFS system is built, lists the
changes made to the book since the last version, and gives hints on how to
find help in case you run into trouble.</para>
</listitem>
<listitem>
<para>Part II describes how to prepare for the building process: making a
partition, downloading the packages, and compiling temporary tools.</para>
</sect2>
<sect2>
<title>Part III - Building the LFS system</title>
partition, downloading the packages, setting up a good working environment,
and compiling temporary tools.</para>
</listitem>
<listitem>
<para>Part III guides you through the building of the LFS system: compiling
and installing all the packages one by one, setting up the boot scripts, and
installing the kernel. The resulting basic Linux system is the foundation
upon which you can build other software, to extend your system in the way
you like.</para>
</sect2>
<sect2>
<title>Part IV - Appendices</title>
</listitem>
<listitem>
<para>Part IV consists of two appendices. The first is an alphabetical list of
all the installed packages, and the second an alphabetical list of all the
installed programs and libraries, mentioning which package installed it.</para>
</sect2>
</listitem>
</itemizedlist>
</sect1>