diff options
author | Alex Gronenwoud <alex@linuxfromscratch.org> | 2004-02-14 14:53:12 +0000 |
---|---|---|
committer | Alex Gronenwoud <alex@linuxfromscratch.org> | 2004-02-14 14:53:12 +0000 |
commit | c3dc67cdcf7eebbffd7d69de741251a0c08443a1 (patch) | |
tree | a37b132efebea419d0555696cb0e70ba007bd87c /chapter05/chapter05.xml | |
parent | cd1ddd744ed1644f30d0dba09fdf49a14e0061b3 (diff) |
Changing a few SBUs.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3251 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
Diffstat (limited to 'chapter05/chapter05.xml')
-rw-r--r-- | chapter05/chapter05.xml | 13 |
1 files changed, 7 insertions, 6 deletions
diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml index 870c02ba6..aa00353a2 100644 --- a/chapter05/chapter05.xml +++ b/chapter05/chapter05.xml @@ -155,7 +155,7 @@ will show you all the files successfully opened during the linking.</para> checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote> <para>This is important for the reasons mentioned above. It also demonstrates -that GCC's configure script does not search the $PATH directories to find which +that GCC's configure script does not search the PATH directories to find which tools to use. However, during the actual operation of <command>gcc</command> itself, the same search paths are not necessarily used. You can find out which standard linker <command>gcc</command> will use by running: @@ -169,7 +169,7 @@ information about the preprocessor, compilation and assembly stages, including <para>The next package installed is Glibc. The most important considerations for building Glibc are the compiler, binary tools and kernel headers. The compiler is generally no problem as Glibc will always use the <command>gcc</command> -found in a $PATH directory. The binary tools and kernel headers can be a little +found in a PATH directory. The binary tools and kernel headers can be a little more troublesome. Therefore we take no risks and use the available configure switches to enforce the correct selections. After the run of <command>./configure</command> you can check the contents of the @@ -525,10 +525,10 @@ problem is and correct it. There is no point in continuing until this is done. First, redo the sanity check using <command>gcc</command> instead of <command>cc</command>. If this works it means the <filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit -<xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your $PATH +<xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your PATH is correct. You can check this by running <userinput>echo $PATH</userinput> and verifying that <filename class="directory">/tools/bin</filename> is at the head -of the list. If the $PATH is wrong it could mean you're not logged in as user +of the list. If the PATH is wrong it could mean you're not logged in as user <emphasis>lfs</emphasis> or something went wrong back in <xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with the specs file amendment above. In this case redo the specs file amendment @@ -586,8 +586,9 @@ that it doesn't recognize their file format. Most of them are scripts instead of binaries.</para> <para>Take care <emphasis>not</emphasis> to use -<emphasis>--strip-unneeded</emphasis> on the libraries -- they would be -destroyed and you would have to build Glibc all over again.</para> +<emphasis>--strip-unneeded</emphasis> on the libraries -- the static ones +would be destroyed and you would have to build the three toolchain packages +all over again.</para> <para>To save another couple of megabytes, you can throw away all the documentation:</para> |