gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-03-05 22:04:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

Small text rearrangement.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2820 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Greg Schafer 2003-09-15 23:12:22 +00:00
parent 1e16325464
commit 1ce39f26fe
1 changed files with 11 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
chapter01/how.xml
View File

@ -16,7 +16,7 @@ partition and filesystem is where your new LFS system will be compiled and
installed onto.</para>
<para>Chapter 5 will then discuss the installation of a number of packages that
will form the basic development suite (or tool-set) which is used to build the
will form the basic development suite (or toolset) 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>
@ -31,7 +31,7 @@ pass.</para>
<para>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,
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. This is known as <quote>self
contained</quote> and <quote>self hosted</quote>. There is a discussion of the
@ -45,19 +45,16 @@ is to ensure that as little information from your host makes it into your new
pristine LFS system. When you build the first two packages in Chapter 5,
Binutils and GCC, they will be compiled statically. This means that the
version of the C library on your host distribution will be embedded inside all
the binary programs you just compiled. This will cause problems for you down
the road (they have been well documented). The host's Glibc is usually an
unknown quantity and can contain bugs or anything else we don't know about
the binary programs you just compiled. This has the potential to cause
problems for you down the road. The host's Glibc is usually an unknown
quantity and might even contain bugs or anything else we don't know about
until it is too late. A well known issue is that statically linked binaries
compiled on a Glibc-2.2.x based system that then contain calls to the
<emphasis>getpwuid()</emphasis> function crash when run on a Glibc-2.3.x based
system. You are
about to build a Glibc-2.3.x based system. You do not want to build something
that is going to crash do you? Finally, the Glibc autoconf tests produce
different results depending on whether an existing Glibc is found on the host
distribution. This can lead to inconsistencies and encourages hacks and
workarounds. With all these things in mind, you can see that the extra effort
to compile Binutils and GCC twice is well worth it.</para>
compiled on a Glibc-2.2.x based system that contain calls to the getpwuid()
function crash when run on a glibc-2.3.x based system. Seeing as we are about
to build a Glibc-2.3.x based system, we need to shield ourselves from problems
of this nature. The procedure employed in Chapter 5 achieves this goal. With
all these things in mind, you can see that the extra effort to compile
Binutils and GCC twice is well worth it.</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