diff options
| -rw-r--r-- | chapter05/adding-user.xml | 24 | ||||
| -rw-r--r-- | chapter05/binutils-pass1-inst.xml | 38 | ||||
| -rw-r--r-- | chapter05/creatingstage1dir.xml | 14 | ||||
| -rw-r--r-- | chapter05/gcc-pass1-inst.xml | 97 | ||||
| -rw-r--r-- | chapter05/glibc-inst.xml | 40 | ||||
| -rw-r--r-- | chapter05/introduction.xml | 15 | ||||
| -rw-r--r-- | chapter05/kernelheaders-inst.xml | 28 | ||||
| -rw-r--r-- | chapter05/lockingglibc.xml | 26 | ||||
| -rw-r--r-- | chapter05/setting-environment.xml | 48 | ||||
| -rw-r--r-- | chapter05/whystatic.xml | 25 |
10 files changed, 178 insertions, 177 deletions
diff --git a/chapter05/adding-user.xml b/chapter05/adding-user.xml index 131368503..8e4881815 100644 --- a/chapter05/adding-user.xml +++ b/chapter05/adding-user.xml @@ -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> diff --git a/chapter05/binutils-pass1-inst.xml b/chapter05/binutils-pass1-inst.xml index 13f478daa..2adbdf700 100644 --- a/chapter05/binutils-pass1-inst.xml +++ b/chapter05/binutils-pass1-inst.xml @@ -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> diff --git a/chapter05/creatingstage1dir.xml b/chapter05/creatingstage1dir.xml index 0a34be4eb..7e4b733a9 100644 --- a/chapter05/creatingstage1dir.xml +++ b/chapter05/creatingstage1dir.xml @@ -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> diff --git a/chapter05/gcc-pass1-inst.xml b/chapter05/gcc-pass1-inst.xml index b290d05f2..e9a649776 100644 --- a/chapter05/gcc-pass1-inst.xml +++ b/chapter05/gcc-pass1-inst.xml @@ -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>--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>--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>--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>--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>--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>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>BOOT_LDFLAGS="-static"</userinput>: This tells +GCC to link its programs statically.</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> diff --git a/chapter05/glibc-inst.xml b/chapter05/glibc-inst.xml index 499b2ae02..b8e84de43 100644 --- a/chapter05/glibc-inst.xml +++ b/chapter05/glibc-inst.xml @@ -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> - -<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> +add-ons that were installed with Glibc, in our case Linuxthreads.</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> diff --git a/chapter05/introduction.xml b/chapter05/introduction.xml index bd0145290..aecb28cfb 100644 --- a/chapter05/introduction.xml +++ b/chapter05/introduction.xml @@ -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 diff --git a/chapter05/kernelheaders-inst.xml b/chapter05/kernelheaders-inst.xml index dac03be82..96f629dd0 100644 --- a/chapter05/kernelheaders-inst.xml +++ b/chapter05/kernelheaders-inst.xml @@ -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>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>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>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 diff --git a/chapter05/lockingglibc.xml b/chapter05/lockingglibc.xml index 95d086467..45a4fe5fb 100644 --- a/chapter05/lockingglibc.xml +++ b/chapter05/lockingglibc.xml @@ -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> diff --git a/chapter05/setting-environment.xml b/chapter05/setting-environment.xml index 45675ea76..20d8f7ea1 100644 --- a/chapter05/setting-environment.xml +++ b/chapter05/setting-environment.xml @@ -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> +source ~/.bash_profile</userinput></screen></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> diff --git a/chapter05/whystatic.xml b/chapter05/whystatic.xml index 59b221e55..86a550154 100644 --- a/chapter05/whystatic.xml +++ b/chapter05/whystatic.xml @@ -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> |