mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-06 06:14:47 +00:00
Changing chapter IDs in anticipation.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3221 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
parent
fe5b13b40b
commit
dcff0464e8
@ -9,26 +9,26 @@ 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="chapter03"/> you will first create a new Linux native
|
||||
<para>In <xref linkend="chapter-making-space"/> 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
|
||||
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>
|
||||
|
||||
<para><xref linkend="chapter05"/> then discusses the installation of a number
|
||||
<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="chapter06"/>. Some of these
|
||||
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>The first thing to be done in <xref linkend="chapter05"/> is build a
|
||||
<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="chapter05"/> packages are all built using
|
||||
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
|
||||
@ -36,10 +36,10 @@ 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="chapter05"/>, including some notes
|
||||
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="chapter06"/> your real LFS system will be built. The
|
||||
<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
|
||||
@ -52,8 +52,8 @@ 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="chapter07"/>, the kernel and bootloader are set up in
|
||||
<xref linkend="chapter08"/>, and <xref linkend="chapter09"/> contains some
|
||||
<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>
|
||||
|
||||
@ -62,9 +62,9 @@ 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="chapter02"/> carefully as it explains a few
|
||||
<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="chapter05"/> and beyond.</para>
|
||||
<xref linkend="chapter-temporary-tools"/> and beyond.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
@ -6,7 +6,7 @@
|
||||
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="chapter03"/>. For the moment let's assume that the LFS partition
|
||||
<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
|
||||
|
@ -12,7 +12,7 @@ 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="chapter05"/>, and the time it
|
||||
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>
|
||||
|
||||
|
@ -16,12 +16,12 @@ 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>
|
||||
|
||||
<para>Experience has shown us that there is little to be gained from running
|
||||
the test suites in <xref linkend="chapter05"/>. There can be no escaping the
|
||||
the test suites in <xref linkend="chapter-temporary-tools"/>. There can be no escaping the
|
||||
fact that the host system always exerts influence on the tests in that chapter,
|
||||
often causing weird and inexplicable failures. Not only that, the tools built
|
||||
in <xref linkend="chapter05"/> are temporary and eventually discarded. For the
|
||||
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="chapter05"/>. The instructions for running those
|
||||
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>
|
||||
|
||||
@ -35,7 +35,7 @@ is running out of pseudo terminals (PTYs for short). The symptom is an
|
||||
unusually high number of failing tests. This can happen for a number of
|
||||
reasons. Most likely 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="chapter05"/>.</para></note>
|
||||
more detail later on in <xref linkend="chapter-temporary-tools"/>.</para></note>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter02" xreflabel="Chapter 2">
|
||||
<chapter id="chapter-preparation" xreflabel="Chapter 2">
|
||||
<title>Important information</title>
|
||||
<?dbhtml filename="chapter02.html" dir="chapter02"?>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter03" xreflabel="Chapter 3">
|
||||
<chapter id="chapter-making-space" xreflabel="Chapter 3">
|
||||
<title>Preparing a new partition</title>
|
||||
<?dbhtml filename="chapter03.html" dir="chapter03"?>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter04" xreflabel="Chapter 4">
|
||||
<chapter id="chapter-getting-materials" xreflabel="Chapter 4">
|
||||
<title>The materials: packages and patches</title>
|
||||
<?dbhtml filename="chapter04.html" dir="chapter04"?>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter05" xreflabel="Chapter 5">
|
||||
<chapter id="chapter-temporary-tools" xreflabel="Chapter 5">
|
||||
<title>Constructing a temporary system</title>
|
||||
<?dbhtml filename="chapter05.html" dir="chapter05"?>
|
||||
|
||||
@ -71,10 +71,10 @@ 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 <xref linkend="chapter05"/> is to provide a sane,
|
||||
<para>The overall goal of <xref linkend="chapter-temporary-tools"/> 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
|
||||
<xref linkend="chapter-building-system"/>. 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
|
||||
@ -109,7 +109,7 @@ the <filename>shlib-versions</filename> file in the root of the Glibc source
|
||||
tree.</para>
|
||||
</important>
|
||||
|
||||
<para>Some key technical points of how the <xref linkend="chapter05"/> build
|
||||
<para>Some key technical points of how the <xref linkend="chapter-temporary-tools"/> build
|
||||
method works:</para>
|
||||
|
||||
<itemizedlist>
|
||||
@ -207,10 +207,10 @@ would defeat our goal of getting away from the host.</para>
|
||||
<emphasis>--with-lib-path</emphasis> configure switch to control
|
||||
<command>ld</command>'s library search path. From this point onwards, the
|
||||
core toolchain is self-contained and self-hosted. The remainder of the
|
||||
<xref linkend="chapter05"/> packages all build against the new Glibc in
|
||||
<xref linkend="chapter-temporary-tools"/> 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 <xref linkend="chapter06"/>, the
|
||||
<para>Upon entering the chroot environment in <xref linkend="chapter-building-system"/>, 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
|
||||
|
@ -50,7 +50,7 @@ process is warranted here. Under normal circumstances, the GCC fixincludes
|
||||
script scans your system for header files that need to be fixed. It might find
|
||||
that some Glibc header files on your host system need to be fixed, fix them and
|
||||
put them in the GCC private include directory. Then, later on in
|
||||
<xref linkend="chapter06"/>, after we've installed the newer Glibc, this
|
||||
<xref linkend="chapter-building-system"/>, 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
|
||||
|
@ -90,7 +90,7 @@ so:</para>
|
||||
system, in particular the kernel. Additionally, here in this chapter some tests
|
||||
can be adversely affected by existing tools or environmental issues on the host
|
||||
system. Of course, these won't be a problem when we run the Glibc test suite
|
||||
inside the chroot environment of <xref linkend="chapter06"/>. In general, the
|
||||
inside the chroot environment of <xref linkend="chapter-building-system"/>. 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>
|
||||
@ -117,9 +117,9 @@ fail due to test timeouts being exceeded.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>In summary, don't worry too much if you see Glibc test suite failures
|
||||
here in this chapter. The Glibc in <xref linkend="chapter06"/> is the one we'll
|
||||
here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> 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
|
||||
But please keep in mind, even in <xref linkend="chapter-building-system"/> 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 <command>make check</command>. The test suite
|
||||
|
@ -48,7 +48,7 @@ here are not surprising, but are not considered critical:</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 will be
|
||||
given later on in <xref linkend="chapter07"/>.</para></listitem>
|
||||
given later on in <xref linkend="chapter-bootscripts"/>.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Sometimes package test suites will give false failures. You can
|
||||
|
@ -41,7 +41,7 @@ or ELF binary), run <command>strip --strip-debug filename</command>.
|
||||
Wildcards can be used to treat multiple files (use something like
|
||||
<userinput>strip --strip-debug $LFS/tools/bin/*</userinput>).</para>
|
||||
|
||||
<para>For your convenience, <xref linkend="chapter09"/> includes one simple
|
||||
<para>For your convenience, <xref linkend="chapter-finalizing"/> 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>
|
||||
|
@ -23,7 +23,7 @@ like something more radical, search the LFS mailing lists for depinit.</para>
|
||||
|
||||
<para>If you decide to use BSD style, or some other style scripts, you can
|
||||
skip the next chapter when you arrive at it and move on to
|
||||
<xref linkend="chapter08"/>.</para>
|
||||
<xref linkend="chapter-mixture"/>.</para>
|
||||
|
||||
<para>Install the boot scripts:</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter06" xreflabel="Chapter 6">
|
||||
<chapter id="chapter-building-system" xreflabel="Chapter 6">
|
||||
<title>Installing basic system software</title>
|
||||
<?dbhtml filename="chapter06.html" dir="chapter06"?>
|
||||
|
||||
@ -269,7 +269,7 @@ freely by the user, as well-written packages don't depend on GID numbers but
|
||||
use the group's name.</para>
|
||||
|
||||
<para>To get rid of the "I have no name!" prompt, we will start a new shell.
|
||||
Since we installed a full Glibc in <xref linkend="chapter05"/>, and have just
|
||||
Since we installed a full Glibc in <xref linkend="chapter-temporary-tools"/>, and have just
|
||||
created the <filename>/etc/passwd</filename> and
|
||||
<filename>/etc/group</filename> files, user name and group name resolution
|
||||
will now work.</para>
|
||||
@ -325,7 +325,7 @@ adjusted linker by running the following from within the
|
||||
|
||||
<note><para>If you somehow missed the earlier warning to retain the Binutils
|
||||
source and build directories from the second pass in
|
||||
<xref linkend="chapter05"/>, or otherwise accidentally deleted them or just
|
||||
<xref linkend="chapter-temporary-tools"/>, or otherwise accidentally deleted them or just
|
||||
don't have access to them, don't worry, all is not lost. Just ignore the above
|
||||
command. The result will be that the next package, Binutils, will link against
|
||||
the Glibc libraries in <filename class="directory">/tools</filename> rather
|
||||
|
@ -28,7 +28,7 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
|
||||
or modifying them when building GCC.</para>
|
||||
|
||||
<para>This is an older release of GCC which we are going to install for the
|
||||
purpose of compiling the Linux kernel in <xref linkend="chapter08"/>. This
|
||||
purpose of compiling the Linux kernel in <xref linkend="chapter-mixture"/>. 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
|
||||
|
@ -92,7 +92,7 @@ compiler. To satisfy those packages, create a symlink:</para>
|
||||
we performed earlier in this chapter. Refer back to
|
||||
<xref linkend="ch-system-adjustingtoolchain"/> and repeat the check. If the results
|
||||
are wrong, then most likely you erroneously applied the GCC Specs patch from
|
||||
<xref linkend="chapter05"/>.</para></note>
|
||||
<xref linkend="chapter-temporary-tools"/>.</para></note>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter07" xreflabel="Chapter 7">
|
||||
<chapter id="chapter-bootscripts" xreflabel="Chapter 7">
|
||||
<title>Setting up system boot scripts</title>
|
||||
<?dbhtml filename="chapter07.html" dir="chapter07"?>
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
<?dbhtml filename="loadkeys.html" dir="chapter07"?>
|
||||
|
||||
<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
|
||||
at the end of <xref linkend="chapter-building-system"/>, 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
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter08" xreflabel="Chapter 8">
|
||||
<chapter id="chapter-mixture" xreflabel="Chapter 8">
|
||||
<title>Making the LFS system bootable</title>
|
||||
<?dbhtml filename="chapter08.html" dir="chapter08"?>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<chapter id="chapter09" xreflabel="Chapter 9">
|
||||
<chapter id="chapter-finalizing" xreflabel="Chapter 9">
|
||||
<title>The End</title>
|
||||
<?dbhtml filename="chapter09.html" dir="chapter09"?>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user