mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-08-03 01:55:46 +01:00
Applied Alex' "apapting-the-text.patch" patch
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2639 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Gerard Beekmans
parent
8f999de57b
commit
66e4325887
@ -2,24 +2,26 @@
|
||||
<title>Adding the user lfs</title>
|
||||
<?dbhtml filename="addinguser.html" dir="chapter05"?>
|
||||
|
||||
<para>If you are logged in as <emphasis>root</emphasis> during Chapter 5,
|
||||
your host system can be damaged by a single mistake. We recommend that
|
||||
you build the packages in Chapter 5 as an unprivileged user. You could use
|
||||
your own user name, but to ensure a clean build environment, we'll create a
|
||||
new user: <emphasis>lfs</emphasis>. As <emphasis>root</emphasis>, issue
|
||||
the following commands to add the new user:</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 commands to add the new user:</para>
|
||||
|
||||
<para><screen><userinput>useradd -s /bin/bash -m lfs
|
||||
passwd lfs</userinput></screen></para>
|
||||
|
||||
<para>In order to grant ownership of the <filename>$LFS/stage1</filename>
|
||||
directory to the user <emphasis>lfs</emphasis>, issue the command:</para>
|
||||
<para>Now grant this new user <emphasis>lfs</emphasis> full access to
|
||||
<filename class="directory">$LFS/stage1</filename> by giving it ownership
|
||||
of the directory:</para>
|
||||
|
||||
<para><screen><userinput>chown lfs $LFS/stage1</userinput></screen></para>
|
||||
|
||||
<para>Next, login as user <emphasis>lfs</emphasis>. This can be accomplished
|
||||
via a virtual console, display manager or with the substitute user
|
||||
command:</para>
|
||||
<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>
|
||||
|
||||
<para><screen><userinput>su - lfs</userinput></screen></para>
|
||||
|
||||
|
||||
@ -3,11 +3,15 @@
|
||||
<sect2>
|
||||
<title>Installation of Binutils</title>
|
||||
|
||||
<para>It is important that Binutils be the first package to get compiled,
|
||||
because both Glibc and GCC perform various tests on the available linker and
|
||||
assembler to determine which of their own features to enable.</para>
|
||||
|
||||
<para>This package is known to behave badly when you have changed its default
|
||||
optimization flags (including the -march and -mcpu options). Therefore, if
|
||||
you have defined any environment variables that override default
|
||||
optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
|
||||
modifying them when building binutils.</para>
|
||||
modifying them when building Binutils.</para>
|
||||
|
||||
<para>It is recommended by the Binutils installation documentation to build
|
||||
Binutils outside of the source directory in a dedicated directory:</para>
|
||||
@ -20,13 +24,16 @@ cd ../binutils-build</userinput></screen></para>
|
||||
<para><screen><userinput>../binutils-&binutils-version;/configure \
|
||||
--prefix=/stage1 --disable-nls</userinput></screen></para>
|
||||
|
||||
<para>The meaning of the (new) configure switches are:</para>
|
||||
<para>The meaning of the configure switches is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><userinput>--disable-nls</userinput>: This option disables
|
||||
internationalization (also known as i18n). We don't need this for our
|
||||
static programs and nls often causes problems when you're linking
|
||||
statically.</para></listitem>
|
||||
<listitem><para><userinput>--prefix=/stage1</userinput>: This tells the
|
||||
configure script to prepare to install the Binutils programs in the
|
||||
<filename>/stage1</filename> directory.</para></listitem>
|
||||
<listitem><para><userinput>--disable-nls</userinput>: This disables
|
||||
internationalization (a word often shortened to i18n). We don't need this
|
||||
for our static programs and <emphasis>nls</emphasis> often causes problems
|
||||
when linking statically.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Continue with compiling the package:</para>
|
||||
@ -36,24 +43,23 @@ statically.</para></listitem>
|
||||
<para>The meaning of the make option is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This is
|
||||
how we tell Binutils that all programs should be statically linked. Setting
|
||||
the <emphasis>LDFLAGS</emphasis> variable is the common way of specifying we
|
||||
want a static link to take place, however, its value and the way it is set
|
||||
is not always the same. You'll see with the remaining packages that there
|
||||
are different ways of setting up the <emphasis>LDFLAGS</emphasis>
|
||||
variable.</para></listitem>
|
||||
<listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells
|
||||
the linker that all the Binutils programs should be linked
|
||||
statically.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>And finish off installing the package:</para>
|
||||
<para>And install the package:</para>
|
||||
|
||||
<para><screen><userinput>make install</userinput></screen></para>
|
||||
|
||||
<para>Now already prepare the linker for the "locking in" of
|
||||
<emphasis>glibc</emphasis> later on:</para>
|
||||
|
||||
<para><screen><userinput>make -C ld clean
|
||||
make -C ld LIB_PATH=/stage1/lib</userinput></screen></para>
|
||||
|
||||
<para>Do not remove the binutils-* directories. We need them again
|
||||
later on in this chapter.</para>
|
||||
<para><emphasis>Do not yet remove</emphasis> the binutils-* directories.
|
||||
We will need them again a bit further on in this chapter.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
@ -11,15 +11,17 @@ required directory by running the following:</para>
|
||||
|
||||
<para><screen><userinput>mkdir $LFS/stage1</userinput></screen></para>
|
||||
|
||||
<para>The next step is to create a "/stage1" symlink on the host system. It
|
||||
will point to the directory we just created on the LFS partition:</para>
|
||||
<para>The next step is to create a <filename>/stage1</filename> symlink on
|
||||
your host system. It will point to the directory we just created on the LFS
|
||||
partition:</para>
|
||||
|
||||
<para><screen><userinput>ln -s $LFS/stage1 /</userinput></screen></para>
|
||||
|
||||
<para>This ensures our toolchain will look in the same place (i.e. /stage1)
|
||||
in both Chapters 5 and 6 (when we are inside the chroot). This is an
|
||||
important concept to grasp. Don't worry if it's not clear right now, all
|
||||
will make sense once we get into Chapter 6.</para>
|
||||
<para>This symlink enables us to compile our toolchain so that it always
|
||||
refers to <filename>/stage1</filename>, meaning that the compiler, assembler
|
||||
and linker will work both in this chapter (when we are still rummaging around
|
||||
on the host) <emphasis>and</emphasis> in the next (when we are chrooted to
|
||||
the LFS partition).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<sect2>
|
||||
<title>Installation of GCC</title>
|
||||
|
||||
<para>We won't be needing a C++ compiler until Chapter 6. So, only
|
||||
<para>We won't be needing a C++ compiler until the next chapter. So, only
|
||||
the gcc-core tarball needs to be unpacked at this time.</para>
|
||||
|
||||
<para>This package is known to behave badly when you have changed its
|
||||
@ -28,79 +28,58 @@ cd ../gcc-build</userinput></screen></para>
|
||||
--disable-nls --enable-shared \
|
||||
--enable-languages=c</userinput></screen></para>
|
||||
|
||||
<para>The meaning of the configure options are:</para>
|
||||
<para>The meaning of the new configure options is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><userinput>--prefix=/static</userinput>: This is NOT a
|
||||
typo. GCC hard codes some paths while compiling and so we need to pass
|
||||
<filename class="directory">/static</filename> as the prefix during the
|
||||
configure stage. We will pass the real installation prefix (<filename
|
||||
class="directory">$LFS/static</filename>) during the installation
|
||||
stage later on.</para></listitem>
|
||||
<listitem><para><userinput>--with-local-prefix=/stage1</userinput>: The
|
||||
purpose of this switch is to remove <filename>/usr/local/include</filename>
|
||||
from <userinput>gcc</userinput>'s include search path. This is not absolutely
|
||||
essential, but we want to try and minimize the influence from the host system,
|
||||
so this seems a logical thing to do.</para></listitem>
|
||||
|
||||
<listitem><para><userinput>--disable-shared</userinput>: This prevents the
|
||||
build of dynamic libraries. They are useless to us at the moment. We'll
|
||||
create them when we reinstall GCC in chapter 6.</para></listitem>
|
||||
<listitem><para><userinput>--enable-shared</userinput>: This switch may
|
||||
seem counter-intuitive at first. But using it allows the building of
|
||||
<filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and
|
||||
having <filename>libgcc_eh.a</filename> available ensures that the configure
|
||||
script for Glibc (the next package we compile) produces the proper results.
|
||||
Please note that the <userinput>gcc</userinput> binaries will still be linked
|
||||
statically, as this is controlled by the <userinput>-static</userinput>
|
||||
value of BOOT_LDFLAGS further on.</para></listitem>
|
||||
|
||||
<listitem><para><userinput>--with-as=$LFS/static/bin/as and
|
||||
--with-ld=$LFS/static/bin/ld</userinput>: GCC can be miscompiled if your
|
||||
host distribution's Binutils package is quite old. We need a good working
|
||||
static GCC until we reinstall GCC later in chapter 6. So by using
|
||||
<filename>as</filename> and <filename>ld</filename> from the Binutils
|
||||
package we compiled earlier in this chapter we ensure that GCC will work
|
||||
correctly.</para></listitem>
|
||||
<listitem><para><userinput>--enable-languages=c</userinput>: This will build
|
||||
only the C compiler from the GCC package. We won't be needing anything else
|
||||
during this chapter.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Continue with compiling the package:</para>
|
||||
|
||||
<para><screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen></para>
|
||||
|
||||
<para>The meaning of the make options are:</para>
|
||||
<para>The meaning of the make parameters is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><userinput>BOOT_LDFLAGS="-static"</userinput>: This is
|
||||
GCC's equivalent to make LDFLAGS="-static" as we use with other packages to
|
||||
compile them statically.</para></listitem>
|
||||
<listitem><para><userinput>BOOT_LDFLAGS="-static"</userinput>: This tells
|
||||
GCC to link its programs statically.</para></listitem>
|
||||
|
||||
<listitem><para><userinput>bootstrap</userinput>: The
|
||||
<emphasis>bootstrap</emphasis> target doesn't just compile GCC, but it
|
||||
compiles GCC a second time. It uses the first compiled programs to compile
|
||||
itself a second and third time to make sure the compiler was compiled properly
|
||||
and can compile itself properly.</para></listitem>
|
||||
<listitem><para><userinput>bootstrap</userinput>: This target doesn't just
|
||||
compile GCC, but compiles it several times. It uses the programs compiled in
|
||||
a first round to compile itself a second time, and then again a third time.
|
||||
It then compares these second and third compiles to make sure it can
|
||||
reproduce itself flawlessly, which most probably means that it was
|
||||
compiled correctly.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>And finish off installing the package:</para>
|
||||
<para>And install the package:</para>
|
||||
|
||||
<para><screen><userinput>make install</userinput></screen></para>
|
||||
|
||||
<para>The meaning of the make option is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><userinput>install-no-fixedincludes</userinput>: This prevents
|
||||
the fixincludes script from running. Preventing this is necessary because
|
||||
under normal circumstances the GCC installation will run the fixincludes
|
||||
script which scans your system for header files that need to be fixed. It
|
||||
might find that the Glibc header files of your host system need to be fixed.
|
||||
If so, it will fix them and put them in
|
||||
<filename>$LFS/static/lib/gcc-lib/i686-pc-linux-gnu/3.2</filename>. Later on
|
||||
in chapter 6 you will install Glibc which will put its header files in
|
||||
<filename>/usr/include</filename>. Next you will install other programs that
|
||||
use the Glibc headers and GCC will look in
|
||||
<filename>/static/lib/gcc-lib</filename> before looking in
|
||||
<filename>/usr/include</filename>, with the result of finding and using the
|
||||
fixed Glibc header files from your host distribution, which are probably
|
||||
incompatible with the Glibc version actually used on the LFS
|
||||
system.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>As the finishing touch we'll create the <filename
|
||||
class="symlink">$LFS/static/bin/cc</filename> symlink. A lot of programs
|
||||
and scripts try to run <userinput>cc</userinput> instead of
|
||||
<userinput>gcc</userinput> This is to keep programs generic and usable on
|
||||
all kinds of Unix systems. Not everybody has GNU CC installed. Just running
|
||||
<userinput>cc</userinput> (C Compiler) leaves the user free to decide which
|
||||
C compiler to install. The symlink will point to the system's default
|
||||
compiler.</para>
|
||||
<para>As a finishing touch we'll create the <filename
|
||||
class="symlink">/stage1/bin/cc</filename> symlink. Many programs and
|
||||
scripts run <userinput>cc</userinput> instead of <userinput>gcc</userinput>,
|
||||
a thing meant to keep programs generic and therefore usable on all kinds of
|
||||
Unix systems. Not everybody has the GNU C compiler installed. Simply running
|
||||
<userinput>cc</userinput> leaves the system administrator free to decide what
|
||||
C compiler to install, as long as there's a symlink pointing to it:</para>
|
||||
|
||||
<para><screen><userinput>ln -sf gcc /stage1/bin/cc</userinput></screen></para>
|
||||
|
||||
|
||||
@ -15,11 +15,11 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
|
||||
them when building Glibc.</para>
|
||||
|
||||
<para>Basically, compiling Glibc in any other way than the book suggests
|
||||
is putting your system at a very high risk.</para>
|
||||
is putting the stability of your system at risk.</para>
|
||||
|
||||
<para>Though it is a harmless message, the install stage of Glibc will
|
||||
complain about the presence of /etc/ld.so.conf (or lack thereof). Fix
|
||||
this annoying little error:</para>
|
||||
complain about the absence of <filename>/etc/ld.so.conf</filename>.
|
||||
Fix this annoying little error with:</para>
|
||||
|
||||
<para><screen><userinput>mkdir /stage1/etc
|
||||
touch /stage1/etc/ld.so.conf</userinput></screen></para>
|
||||
@ -38,7 +38,7 @@ cd ../glibc-build</userinput></screen></para>
|
||||
--with-binutils=/stage1/bin \
|
||||
--without-gd</userinput></screen></para>
|
||||
|
||||
<para>The meaning of the configure options are:</para>
|
||||
<para>The meaning of the new configure options is:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><userinput>--disable-profile</userinput>: This disables the
|
||||
@ -46,11 +46,18 @@ building of the libraries with profiling information. Omit this option if you
|
||||
plan to do profiling.</para></listitem>
|
||||
|
||||
<listitem><para><userinput>--enable-add-ons</userinput>: This enables any
|
||||
add-ons that we installed with Glibc, in our case Linuxthreads.</para></listitem>
|
||||
add-ons that were installed with Glibc, in our case Linuxthreads.</para></listitem>
|
||||
|
||||
<listitem><para><userinput>--libexecdir=/usr/bin</userinput>: This will
|
||||
cause the <filename>pt_chown</filename> program to be installed in the
|
||||
<filename>/usr/bin</filename> directory.</para></listitem>
|
||||
<listitem><para><userinput>--with-binutils=/stage1/bin</userinput> and
|
||||
<userinput>--with-headers=/stage1/include</userinput>: Strictly speaking
|
||||
these switches are not required. But they ensure nothing can go wrong with
|
||||
regard to what kernel headers and Binutils programs get used during the
|
||||
Glibc build.</para></listitem>
|
||||
|
||||
<listitem><para><userinput> --without-gd</userinput>: This switch ensures
|
||||
that we don't build the <userinput>memusagestat</userinput> program, which
|
||||
strangely enough insists on linking against the host's libraries (libgd,
|
||||
libpng, libz, and so forth).</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>During this stage you will see the following warning:</para>
|
||||
@ -76,16 +83,17 @@ would require you to regenerate the binary files.</para>
|
||||
make check
|
||||
make install</userinput></screen></para>
|
||||
|
||||
<para>The locales (used by Glibc to make your Linux system talk in a different
|
||||
language) weren't installed when you ran the previous command, so we have to
|
||||
do that ourselves now:</para>
|
||||
<para>The locales (used by Glibc to make your Linux system respond in a
|
||||
different language) weren't installed when you ran the previous command,
|
||||
so we have to do that ourselves now:</para>
|
||||
|
||||
<para><screen><userinput>make localedata/install-locales</userinput></screen></para>
|
||||
|
||||
<para>An alternative to running the previous command is to install only those
|
||||
locales which you need or want. This can be achieved using the localedef
|
||||
command. Information on this can be found in the <filename>INSTALL</filename>
|
||||
file in the <filename>glibc-&glibc-version;</filename> tree.</para>
|
||||
<para>An alternative to running the previous command is to install only
|
||||
those locales which you need or want. This can be achieved by using the
|
||||
<userinput>localedef</userinput> command. Information on this can be
|
||||
found in the <filename>INSTALL</filename> file in the
|
||||
<filename>glibc-&glibc-version;</filename> tree.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
@ -6,16 +6,23 @@
|
||||
Linux system. This system will contain just enough tools to be able
|
||||
to start constructing the final LFS system in the next chapter.</para>
|
||||
|
||||
<para>The building of this minimal system is done in two steps: first we
|
||||
build a brand-new and host-independent toolchain (compiler, assembler,
|
||||
linker and libraries), and then use this to build all the other essential
|
||||
tools.</para>
|
||||
|
||||
<para>The files compiled in this chapter will be installed under the
|
||||
<filename class="directory">$LFS/static</filename> directory,
|
||||
<filename class="directory">$LFS/stage1</filename> directory,
|
||||
to keep them separate from the files installed in the next chapter.
|
||||
Since the packages compiled here are merely temporary, we don't want
|
||||
them to pollute the soon-to-be LFS system.</para>
|
||||
|
||||
<para>The key to learning what makes a Linux system work is to know
|
||||
exactly what each package is used for, and why the user or the system
|
||||
needs it. For this purpose a short description of the content of each
|
||||
package is given right after the installation instructions.</para>
|
||||
what each package is used for, why the user or the system needs it.
|
||||
For this purpose a short summary of the content of each package is given
|
||||
before the actual installation instructions. For a short description of
|
||||
each program in a package, please refer to the corresponding section in
|
||||
<xref linkend="appendixa"/>.</para>
|
||||
|
||||
<para>Several of the packages are patched before compilation, but only when
|
||||
the patch is needed to circumvent a problem. Often the patch is needed in
|
||||
|
||||
@ -3,27 +3,11 @@
|
||||
<sect2>
|
||||
<title>Installation of the kernel headers</title>
|
||||
|
||||
<para>We won't be compiling a new kernel yet -- we'll do that when we have
|
||||
finished the installation of all the packages. But as some packages need the
|
||||
kernel header files, we're going to unpack the kernel archive now, set it up
|
||||
and copy the header files so they can be found by these packages.</para>
|
||||
<para>As some packages need to refer to the kernel header files, we're going
|
||||
to unpack the kernel archive now, set it up, and copy the required files to a
|
||||
place where <userinput>gcc</userinput> can later find them.</para>
|
||||
|
||||
<para>It is important to note that the files in the kernel source directory
|
||||
are not owned by <emphasis>root</emphasis>. Whenever you unpack a package as
|
||||
user <emphasis>root</emphasis> (like we do here inside chroot), the files end
|
||||
up having the user and group IDs of whatever they were on the packager's
|
||||
computer. This is usually not a
|
||||
problem for any other package you install because you remove the source
|
||||
tree after the installation. But the Linux kernel source tree is often kept
|
||||
around for a long time, so there's a chance that whatever user ID the packager
|
||||
used will be assigned to somebody on your machine and then that person would
|
||||
have write access to the kernel source.</para>
|
||||
|
||||
<para>In light of this, you might want to run <userinput>chown -R 0:0</userinput>
|
||||
on the <filename>linux-&kernel-version;</filename> directory
|
||||
to ensure all files are owned by user <emphasis>root</emphasis>.</para>
|
||||
|
||||
<para>Prepare for header installation:</para>
|
||||
<para>Prepare for the header installation with:</para>
|
||||
|
||||
<para><screen><userinput>make mrproper</userinput></screen></para>
|
||||
|
||||
@ -41,7 +25,7 @@ symlink:</para>
|
||||
|
||||
<para><screen><userinput>make symlinks</userinput></screen></para>
|
||||
|
||||
<para>Install the platform specific-header files:</para>
|
||||
<para>Install the platform-specific header files:</para>
|
||||
|
||||
<para><screen><userinput>mkdir /stage1/include/asm
|
||||
cp include/asm/* /stage1/include/asm
|
||||
|
||||
@ -5,12 +5,27 @@
|
||||
<sect2><title> </title><para> </para></sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installation of Binutils</title>
|
||||
<title>Installation of the linker scripts</title>
|
||||
|
||||
<para><screen><userinput>make -C ld install-data-local</userinput></screen></para>
|
||||
|
||||
<para>You can remove the binutils-* directories now.</para>
|
||||
<para>This installs the adjusted linker scripts. Remember they were adjusted
|
||||
a little while back, at the end of the first pass of Binutils? The linker
|
||||
scripts now contain no mention of <filename>/lib</filename>,
|
||||
<filename>/usr/lib</filename> or <filename>/usr/local/lib</filename>.
|
||||
From this point onwards everything will link <emphasis>only</emphasis>
|
||||
against the libraries in <filename>/stage1/lib</filename>.</para>
|
||||
|
||||
<para>You can now remove the binutils-* directories.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Amending GCC's specs file</title>
|
||||
|
||||
<para>The final thing to do is to amend our GCC specs file so that it points
|
||||
to the new dynamic linker. A simple sed will accomplish this:</para>
|
||||
|
||||
<para><screen><userinput>SPECFILE=/stage1/lib/gcc-lib/*/*/specs
|
||||
sed -e 's@/lib/ld.so.1@/stage1/lib/ld.so.1@g' \
|
||||
-e 's@/lib/ld-linux.so.2@/stage1/lib/ld-linux.so.2@g' \
|
||||
@ -18,6 +33,13 @@ sed -e 's@/lib/ld.so.1@/stage1/lib/ld.so.1@g' \
|
||||
mv XX $SPECFILE
|
||||
unset SPECFILE</userinput></screen></para>
|
||||
|
||||
<para>We recommend that you cut-and-paste the above rather than try and type
|
||||
it all in. Or you can edit the specs file by hand if you want to: just replace
|
||||
"/lib/ld-linux.so.2" with "/stage1/lib/ld-linux.so.2".</para>
|
||||
|
||||
<para>This completes the installation of the self-contained toolchain, which
|
||||
can now be used to build the rest of the temporary tools.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<sect1 id="ch05-settingenviron">
|
||||
<title>Setting up the environment</title>
|
||||
<?dbhtml filename="settingenviron.html" dir="chapter05"?>
|
||||
<?dbhtml filename="settingenvironment.html" dir="chapter05"?>
|
||||
|
||||
<para>While logged in as user <emphasis>lfs</emphasis>, issue the
|
||||
following commands to set up a good work environment:</para>
|
||||
@ -13,41 +13,41 @@ LC_ALL=POSIX
|
||||
PATH=/stage1/bin:$PATH
|
||||
export LFS LC_ALL PATH
|
||||
EOF
|
||||
|
||||
source ~/.bash_profile</userinput></screen></para>
|
||||
|
||||
<para><userinput>set +h</userinput> turns off Bash's hash function. Hash
|
||||
normally is a useful feature where Bash uses a hash table to remember the
|
||||
full pathnames of executable files to avoid multiple `PATH' searches.
|
||||
However, we'd like the new tools to become available as soon as they are
|
||||
installed. By switching off the hash function, our "interactive" commands
|
||||
(make, patch, sed, cp and so forth) will always use the newest available
|
||||
during the build process.</para>
|
||||
|
||||
<para>This profile sets the umask to 022, so newly created files and
|
||||
directories will have the correct permissions. To be more specific, only
|
||||
the file owner will have write permission to new files and directories.
|
||||
Other users of the system will be have read permission, and executable
|
||||
permission to directories. It is advisable to keep this setting throughout
|
||||
your LFS installation.</para>
|
||||
<para>The <userinput>set +h</userinput> command turns off
|
||||
<userinput>bash</userinput>'s hash function. Normally hashing is a useful
|
||||
feature: <userinput>bash</userinput> 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 (<userinput>make</userinput>,
|
||||
<userinput>patch</userinput>, <userinput>sed</userinput>,
|
||||
<userinput>cp</userinput> 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 <emphasis>glibc</emphasis> older than 2.2.4,
|
||||
having LC_ALL set to something other than "C" or "POSIX" during this chapter
|
||||
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" ("C" is an alias for "POSIX") we ensure that
|
||||
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>LDFLAGS is a variable we set in order to prevent debugging symbols from
|
||||
being compiled into our static packages. By omitting these symbols during
|
||||
the linking stage of compilation, we save hard drive space and decrease our
|
||||
build time.</para>
|
||||
<para>We prepend <filename>/stage1/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>We are now prepared to begin building the temporary tools which will
|
||||
support us in later chapters.</para>
|
||||
<para>Now, after sourcing the just-created profile, we're all set to begin
|
||||
building the temporary tools that will support us in later chapters.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
@ -42,23 +42,14 @@ of the improved function.</para>
|
||||
memory space, disk space, and recompile time.</para>
|
||||
|
||||
<para>But if dynamic linking saves so much space, why then are we linking
|
||||
all programs in this chapter statically? The reason is that we won't be
|
||||
compiling a temporary <filename>glibc</filename> here. And we avoid doing this
|
||||
simply to save some time -- around 14 SBUs. Another reason is that the
|
||||
Glibc version on the LFS system might not be compatible with the Glibc on
|
||||
the host system. Applications compiled against your host system's Glibc
|
||||
version may not run properly (or at all) on the LFS system.</para>
|
||||
|
||||
<para>This means that the tools compiled in this chapter will have to be
|
||||
self-contained, because when later on we chroot to the LFS partition the
|
||||
GNU library won't be available. That is why we use the
|
||||
<userinput>-static</userinput>, <userinput>--enable-static-link</userinput>,
|
||||
and <userinput>--disable-shared</userinput> flags throughout this chapter, to
|
||||
ensure that all executables are statically linked. When we come to the next
|
||||
chapter, almost the first thing we do is build <filename>glibc</filename>, the
|
||||
main set of system libraries. Once this is done, we can link all other programs
|
||||
dynamically (including the ones installed statically in this chapter) and
|
||||
take advantage of the space saving opportunities.</para>
|
||||
the first two packages in this chapter statically? The reason is to make them
|
||||
independent from the libraries on your host system. And the point in that is
|
||||
that, if you are pressed for time, you could skip the second passes over GCC
|
||||
and Binutils, and just use the static versions to compile the rest of this
|
||||
chapter and the first few packages in the next. As in the next chapter we
|
||||
will be chrooted to the LFS partition and your host system's Glibc won't be
|
||||
available, the programs from GCC and Binutils will need to be self-contained,
|
||||
that is statically linked.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user