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

Adding several cross reference tags.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3037 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud 2003-10-24 17:28:42 +00:00
parent 494f01fcd6
commit 7f1fcd89bb
24 changed files with 133 additions and 116 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
appendixa/appendixa.xml
View File

@ -1,4 +1,4 @@
<appendix id="appendixa">
<appendix id="appendixa" xreflabel="Appendix A">
<title>Package descriptions and dependencies</title>
<?dbhtml filename="appendixa.html" dir="appendixa"?>

2
appendixb/appendixb.xml
View File

@ -1,4 +1,4 @@
<appendix id="appendixb">
<appendix id="appendixb" xreflabel="Appendix B">
<title>Index of programs and library files</title>
<?dbhtml filename="appendixb.html" dir="appendixb"?>

7
chapter01/changelog.xml
View File

@ -101,6 +101,9 @@ the <filename>/etc/lfs</filename> filename to
<filename>/etc/lfs-release</filename> to be more consistent with other
distributions out there.</para></listitem>
<listitem><para>October 23rd, 2003 [alex]: Changed most of the "Chapter"
references to proper "xref" cross references .</para></listitem>
<listitem><para>October 22nd, 2003 [gerard] Chapter 2: Added notes how to
create installation dependency lists.</para></listitem>
@ -416,11 +419,11 @@ used in the gzip installation. Closes bug 551.</para></listitem>
patches: Added a note regarding Tushar's patches project, and a link
to the patches home page.</para></listitem>
<listitem><para>September 3rd, 2003 [matt]: Fixed issue with util-linux not
<listitem><para>September 3rd, 2003 [matt]: Fixed issue with Util-linux not
utilizing headers and libraries installed in /stage1.</para></listitem>
<listitem><para>September 3rd, 2003 [matt]: Removed "rm /bin/pwd" instruction
from chapter06 kernel-headers installation as the link is still required by
from Chapter 6 kernel-headers installation as the link is still required by
Glibc's installation.</para></listitem>
<listitem><para>September 2nd, 2003 [alex]: Adjusted all the SBUs from the

2
chapter01/chapter01.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter01">
<chapter id="chapter01" xreflabel="Chapter 1">
<title>Introduction</title>
<?dbhtml filename="chapter01.html" dir="chapter01"?>

88
chapter01/how.xml
View File

@ -9,60 +9,62 @@ 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 Chapter 3 you will first create a new Linux native partition and file
system, the place where your new LFS system will be compiled and installed. Then
in Chapter 4 you download all the packages and patches required to build an LFS
system, and store them on the new file system.</para>
<para>In <xref linkend="chapter03"/> you will first create a new Linux native
partition and file system, the place where your new LFS system will be compiled
and installed. Then in <xref linkend="chapter04"/> you download all the
packages and patches required to build an LFS system, and store them on the new
file system.</para>
<para>Chapter 5 will then discuss 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 Chapter 6. Some of these packages are needed to resolve
circular dependencies. For example, to compile a compiler you need a
compiler.</para>
<para><xref linkend="chapter05"/> 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="chapter06"/>. Some of these
packages are needed to resolve circular dependencies -- for example, to compile
a compiler you need a compiler.</para>
<para>The first thing to be done in Chapter 5 is build a first pass of the
toolchain, which is made up of Binutils and GCC. The programs from these
packages will be linked statically in order for them to be used 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 Chapter 5 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="chapter05"/> 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="chapter05"/> 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>You may be asking yourself <quote>that seems like a lot of work, just to
get away from my host distribution?</quote>. A full technical and in-depth
explanation is provided at the start of Chapter 5, including some notes on the
differences between statically and dynamically linked programs.</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="chapter05"/>, including some notes
on the differences between statically and dynamically linked programs.</para>
<para>In Chapter 6 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.
Another 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="chapter06"/> 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>When all the software from Chapter 6 is installed, the temporary tools
built in Chapter 5 are removed. In Chapters 7, 8 and 9 the installation will
then be finalized. The bootscripts are set up in Chapter 7, the kernel and
bootloader are set up in Chapter 8, and Chapter 9 has 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>To finish the installation, the bootscripts are set up in
<xref linkend="chapter07"/>, the kernel and bootloader are set up in
<xref linkend="chapter08"/>, and <xref linkend="chapter09"/> 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 Chapter 2 carefully as it explains a few important things you
should be aware of before you begin to work through Chapters 5 and
beyond.</para>
<para>Please read <xref linkend="chapter02"/> carefully as it explains a few
important things you should be aware of before you begin to work through
<xref linkend="chapter05"/> and beyond.</para>
</sect1>

4
chapter02/aboutlfs.xml
View File

@ -6,8 +6,8 @@
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
Chapter 3. For the moment let's assume that the LFS partition is mounted on
<filename>/mnt/lfs</filename>.</para>
<xref linkend="chapter03"/>. 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

2
chapter02/chapter02.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter02">
<chapter id="chapter02" xreflabel="Chapter 2">
<title>Important information</title>
<?dbhtml filename="chapter02.html" dir="chapter02"?>

2
chapter03/chapter03.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter03">
<chapter id="chapter03" xreflabel="Chapter 3">
<title>Preparing a new partition</title>
<?dbhtml filename="chapter03.html" dir="chapter03"?>

2
chapter04/chapter04.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter04">
<chapter id="chapter04" xreflabel="Chapter 4">
<title>The materials: packages and patches</title>
<?dbhtml filename="chapter04.html" dir="chapter04"?>

3
chapter05/binutils-pass2-inst.xml
View File

@ -30,7 +30,8 @@ variables that override the default optimization flags.</para>
<screen><userinput>make </userinput></screen>
<note><para>It's worth pointing out that running the Binutils test suite here
is considered not as important as running it in Chapter 6.</para></note>
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>Test the results (there should be no unexpected failures here, expected
failures are fine):</para>

2
chapter05/chapter05.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter05">
<chapter id="chapter05" xreflabel="Chapter 5">
<title>Constructing a temporary system</title>
<?dbhtml filename="chapter05.html" dir="chapter05"?>

14
chapter05/gcc-pass2-inst.xml
View File

@ -38,11 +38,12 @@ briefly earlier, but a slightly more in-depth explanation of the fixincludes
process is warranted here. Under normal circumstances, the GCC fixincludes
script scans your system for header files that need to be fixed. It might find
that some Glibc header files on your host system need to be fixed, fix them and
put them in the GCC private include directory. Then, later on in Chapter 6,
after we've installed the newer Glibc, this private include directory would be
searched before the system include directory, resulting in GCC finding the
fixed headers from the host system, which would most likely not match the Glibc
version actually used for the LFS system.</para>
put them in the GCC private include directory. Then, later on in
<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
private include directory would be searched before the system include
directory, resulting in GCC finding the fixed headers from the host system,
which would most likely not match the Glibc version actually used for the LFS
system.</para>
<para>The last patch changes GCC's default location of the dynamic linker
(typically <filename>ld-linux.so.2</filename>). It also removes
@ -105,7 +106,8 @@ as the compiler we're using to compile this GCC was built from the exact same
version of the GCC sources we used earlier.</para>
<note><para>It's worth pointing out that running the GCC test suite here
is considered not as important as running it in Chapter 6.</para></note>
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>Test the results:</para>

24
chapter05/glibc-inst.xml
View File

@ -9,8 +9,9 @@ Glibc-linuxthreads in that directory, not in the directory where you usually
unpack all the sources.</para>
<note><para>We are going to run the test suite for Glibc in this chapter.
However, it's worth pointing out that running the Glibc test suite here
is considered not as important as running it in Chapter 6.</para></note>
However, it's worth pointing out that running the Glibc test suite here
is considered not as important as running it in
<xref linkend="chapter06"/>.</para></note>
<para>This package is known to behave badly when you have changed its
default optimization flags (including the -march and -mcpu options).
@ -89,13 +90,13 @@ running the test suite.</para>
<screen><userinput>make check</userinput></screen>
<para>The Glibc test suite is highly dependent on certain functions of your host
system, in particular the kernel. Additionally, here in Chapter 5 some tests
system, in particular the kernel. Additionally, here in this chapter some tests
can be adversely affected by existing tools or environmental issues on the host
system. Of course, these won't be a problem when we run the Glibc test suite
inside the chroot environment of Chapter 6. In general, the Glibc test suite is
always expected to pass. However, as mentioned above, some failures are
unavoidable in certain circumstances. Here is a list of the most common issues
we are aware of:</para>
inside the chroot environment of <xref linkend="chapter06"/>. In general, the
Glibc test suite is always expected to pass. However, as mentioned above, some
failures are unavoidable in certain circumstances. Here is a list of the most
common issues we are aware of:</para>
<itemizedlist>
<listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
@ -118,10 +119,11 @@ the kernel.</para></listitem>
fail due to test timeouts being exceeded.</para></listitem>
</itemizedlist>
<para>In summary, don't worry too much if you see Glibc test suite failures here
in Chapter 5. The Glibc in Chapter 6 is the one we'll ultimately end up using so
that is the one we would really like to see pass. But please keep in mind, even
in Chapter 6 some failures could still occur -- the <emphasis>math</emphasis>
<para>In summary, don't worry too much if you see Glibc test suite failures
here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
ultimately end up using so that is the one we would really like to see pass.
But please keep in mind, even in <xref linkend="chapter06"/> some failures
could still occur -- the <emphasis>math</emphasis>
tests for example. When experiencing a failure, make a note of it, then
continue by reissuing the <userinput>make check</userinput>. The test suite
should pick up where it left off and continue on. You can circumvent this

12
chapter05/tcl-inst.xml
View File

@ -18,11 +18,11 @@ to know that our most important tools are working properly.</para>
<screen><userinput>make</userinput></screen>
<para>This package has a test suite available which can perform a number of
checks to ensure it built correctly. However, the Tcl test suite here in
Chapter 5 is known to experience failures under certain host conditions that
are not fully understood. Therefore, test suite failures here are not
surprising, but are not considered critical. Should you choose to run the test
suite, the following command will do so:</para>
checks to ensure it built correctly. However, the Tcl test suite in this
chapter is known to experience failures under certain host conditions that are
not fully understood. Therefore, test suite failures here are not surprising,
but are not considered critical. Should you choose to run the test suite, the
following command will do so:</para>
<screen><userinput>TZ=UTC make test</userinput></screen>
@ -33,7 +33,7 @@ suite, the following command will do so:</para>
Coordinated Universal Time (UTC) also known as Greenwich Mean Time (GMT), but
only for the duration of the test suite run. This ensures the clock tests are
exercised correctly. More information on the TZ environment variable is
available later on in Chapter 7.</para></listitem>
available later on in <xref linkend="chapter07"/>.</para></listitem>
</itemizedlist>
<para>Sometimes, package test suites will give false failures. You can

47
chapter05/toolchaintechnotes.xml
View File

@ -7,11 +7,12 @@ details behind the overall build method. It's not essential that you understand
everything here immediately. Most of it will make sense once you have performed
an actual build. Feel free to refer back here at any time.</para>
<para>The overall goal of Chapter 5 is to provide a sane, temporary environment
that we can chroot into, and from which we can produce a clean, trouble-free
build of the target LFS system in Chapter 6. Along the way, we attempt to
divorce ourselves from the host system as much as possible, and in so doing
build a self-contained and self-hosted toolchain. It should be noted that the
<para>The overall goal of <xref linkend="chapter05"/> is to provide a sane,
temporary environment that we can chroot into, and from which we can produce a
clean, trouble-free build of the target LFS system in
<xref linkend="chapter06"/>. Along the way, we attempt to divorce ourselves
from the host system as much as possible, and in so doing build a
self-contained and self-hosted toolchain. It should be noted that the
build process has been designed in such a way so as to minimize the risks for
new readers and provide maximum educational value at the same time. In other
words, more advanced techniques could be used to build the system.</para>
@ -44,7 +45,8 @@ the <filename>shlib-versions</filename> file in the root of the Glibc source
tree.</para>
</important>
<para>Some key technical points of how the Chapter 5 build method works:</para>
<para>Some key technical points of how the <xref linkend="chapter05"/> build
method works:</para>
<itemizedlist>
<listitem><para>Similar in principle to cross compiling whereby tools installed
@ -128,8 +130,9 @@ hard-wired path to a dynamic linker is embedded into every ELF shared
executable. You can inspect this by running:
<userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>.
By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
program compiled from here through the end of Chapter 5 will use our new
dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
program compiled from here through the end of <xref linkend="chapter05"/> will
use our new dynamic linker in
<filename class="directory">/tools/lib</filename>.</para>
<para>The need to use the new dynamic linker is also the reason why we apply the
Specs patch for the second pass of GCC. Failure to do so will result in the GCC
@ -141,14 +144,15 @@ would defeat our goal of getting away from the host.</para>
<emphasis>--with-lib-path</emphasis> configure switch to control
<userinput>ld</userinput>'s library search path. From this point onwards, the
core toolchain is self-contained and self-hosted. The remainder of the
Chapter 5 packages all build against the new Glibc in
<xref linkend="chapter05"/> packages all build against the new Glibc in
<filename class="directory">/tools</filename> and all is well.</para>
<para>Upon entering the chroot environment in Chapter 6, the first major package
we install is Glibc, due to its self-sufficient nature that we mentioned above.
Once this Glibc is installed into <filename class="directory">/usr</filename>,
we perform a quick changeover of the toolchain defaults, then proceed for real
in building the rest of the target Chapter 6 LFS system.</para>
<para>Upon entering the chroot environment in <xref linkend="chapter06"/>, the
first major package we install is Glibc, due to its self-sufficient nature that
we mentioned above. Once this Glibc is installed into
<filename class="directory">/usr</filename>, we perform a quick changeover of
the toolchain defaults, then proceed for real in building the rest of the
target <xref linkend="chapter06"/> LFS system.</para>
<sect2>
<title>Notes on static linking</title>
@ -180,14 +184,15 @@ library function gets a bug fixed or is otherwise improved, you only need to
recompile this one library, instead of having to recompile all the programs that
make use of the improved function.</para>
<para>Why do we statically link the first two packages in Chapter 5? The reasons
are threefold: historical, educational and technical. Historical because earlier
versions of LFS statically linked every program in Chapter 5. Educational
because knowing the difference is useful. Technical because we gain an element
of independence from the host in doing so, i.e. those programs can be used
<para>If dynamic linking has several advantages, why then do we statically link
the first two packages in this chapter? The reasonsare threefold: historical,
educational, and technical. Historical, because earlier versions of LFS
statically linked every program in this chapter. Educational, because knowing
the difference is useful. Technical, because we gain an element of independence
from the host in doing so, meaning that those programs can be used
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>
successful LFS build can still be achieved when the first two packages are
built dynamically.</para>
</sect2>

6
chapter06/aboutdebug.xml
View File

@ -41,9 +41,9 @@ or ELF binary), run <userinput>strip --strip-debug filename</userinput>.
Wildcards can be used to treat multiple files (use something like
<userinput>strip --strip-debug $LFS/tools/bin/*</userinput>).</para>
<para>For your convenience, Chapter 9 includes one simple command to strip
all debugging symbols from all programs and libraries on your system.
Additional information on optimization can be found in the hint at
<para>For your convenience, <xref linkend="chapter09"/> includes one simple
command to strip all debugging symbols from all programs and libraries on your
system. Additional information on optimization can be found in the hint at
<ulink url="&hints-root;optimization.txt"/>.</para>
</sect1>

3
chapter06/bootscripts-inst.xml
View File

@ -10,7 +10,8 @@ scripts, to be found at <ulink url="&hints-root;bsd-init.txt"/>. And if you'd
like something more radical, search the LFS mailing lists for depinit.</para>
<para>If you decide to use BSD style, or some other style scripts, you can
skip Chapter 7 when you arrive at it and move on to Chapter 8.</para>
skip the next chapter when you arrive at it and move on to
<xref linkend="chapter08"/>.</para>
<para>Install the boot scripts:</para>

2
chapter06/chapter06.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter06">
<chapter id="chapter06" xreflabel="Chapter 6">
<title>Installing basic system software</title>
<?dbhtml filename="chapter06.html" dir="chapter06"?>

3
chapter06/gcc-2953-inst.xml
View File

@ -10,7 +10,8 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
or modifying them when building GCC.</para>
<para>This is an older release of GCC which we are going to install for the
purpose of compiling the Linux kernel in Chapter 8. This version is recommended
purpose of compiling the Linux kernel in <xref linkend="chapter08"/>. This
version is recommended
by the kernel developers when you need absolute stability. Later versions of
GCC have not received as much testing for Linux kernel compilation. Using a
later version is likely to work, however, we recommend adhering to the kernel

2
chapter06/procps-inst.xml
View File

@ -3,7 +3,7 @@
<sect2>
<title>Installation of Procps</title>
<para>First fix a locale problem that can crash <userinput>w</userinput> under
<para>First fix a problem that can crash <userinput>w</userinput> under
certain locale settings:</para>
<screen><userinput>patch -Np1 -i ../&procps-patch;</userinput></screen>

2
chapter07/chapter07.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter07">
<chapter id="chapter07" xreflabel="Chapter 7">
<title>Setting up system boot scripts</title>
<?dbhtml filename="chapter07.html" dir="chapter07"?>

14
chapter07/loadkeys.xml
View File

@ -2,13 +2,13 @@
<title>Do I need the loadkeys script?</title>
<?dbhtml filename="loadkeys.html" dir="chapter07"?>
<para>If you decided to compile your keymap file directly into the kernel
back at the end of Chapter 6, then you strictly speaking don't need to run
this loadkeys script, since the kernel has already set up the keymap for
you. You can still run it if you want, it isn't going to hurt you. It could
even be beneficial to keep it in case you run a lot of different kernels
and don't remember or want to compile the keymap into every kernel you lay
your hands on.</para>
<para>If you decided to compile your keymap file directly into the kernel back
at the end of <xref linkend="chapter06"/>, then you strictly speaking don't
need to run this loadkeys script, since the kernel has already set up the
keymap for you. You can still run it if you want, it isn't going to hurt you.
It could even be beneficial to keep it in case you run a lot of different
kernels and don't remember or want to compile the keymap into every kernel you
lay your hands on.</para>
<para>If you decided you don't need to, or don't want to use the loadkeys
script, remove the

2
chapter08/chapter08.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter08">
<chapter id="chapter08" xreflabel="Chapter 8">
<title>Making the LFS system bootable</title>
<?dbhtml filename="chapter08.html" dir="chapter08"?>

2
chapter09/chapter09.xml
View File

@ -1,4 +1,4 @@
<chapter id="chapter09">
<chapter id="chapter09" xreflabel="Chapter 9">
<title>The End</title>
<?dbhtml filename="chapter09.html" dir="chapter09"?>