mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-06-19 03:39:20 +01:00
Shifting chapter contents, and moving preparational sections of chapter 5 to a separate chapter.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3284 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud
parent
4f4b4e84a2
commit
c6b5ddb7a6
2
book.xml
2
book.xml
@ -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
103
chapter01/askforhelp.xml
Normal 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>
|
||||
|
||||
@ -5,5 +5,6 @@
|
||||
&c1-how;
|
||||
&c1-changelog;
|
||||
&c1-resources;
|
||||
&c1-askforhelp;
|
||||
|
||||
</chapter>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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 <enter URL when it's available>.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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 \
|
||||
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>
|
||||
|
||||
|
||||
@ -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 \
|
||||
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 > ~/.bash_profile << "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 > ~/.bashrc << "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>
|
||||
|
||||
|
||||
@ -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 > ~/.bash_profile << "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 > ~/.bashrc << "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>
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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">
|
||||
|
||||
@ -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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user