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

Minor touchups.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2969 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Greg Schafer 2003-10-12 01:17:37 +00:00
parent f27835d93f
commit a3f6e12435
4 changed files with 9 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
chapter05/gcc-pass2-inst.xml
View File

@ -24,9 +24,6 @@ are able to resolve the issue. You can consult the LFS Wiki at
<ulink url="http://wiki.linuxfromscratch.org/"/> for more information on how to <ulink url="http://wiki.linuxfromscratch.org/"/> for more information on how to
get PTYs working.</para> get PTYs working.</para>
<note><para>It's worth pointing out that the GCC test suite we run in this
section is considered not as important as the one we run in Chapter 6.</para></note>
<para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the <para>Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
same working directory. They will all unfold into a single same working directory. They will all unfold into a single
<filename>gcc-&gcc-version;/</filename> subdirectory.</para> <filename>gcc-&gcc-version;/</filename> subdirectory.</para>

12
chapter05/toolchaintechnotes.xml
View File

@ -38,7 +38,7 @@ something completely different. You should be able to determine the name
of your platform's dynamic linker by looking in the of your platform's dynamic linker by looking in the
<filename class="directory">/lib</filename> directory on your host system. A <filename class="directory">/lib</filename> directory on your host system. A
surefire way is to inspect a random binary from your host system by running: surefire way is to inspect a random binary from your host system by running:
<userinput>`readelf -l &lt;name of binary&gt; | grep interpreter`</userinput> <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>
and noting the output. The authoritative reference covering all platforms is in and noting the output. The authoritative reference covering all platforms is in
the <filename>shlib-versions</filename> file in the root of the Glibc source the <filename>shlib-versions</filename> file in the root of the Glibc source
tree.</para> tree.</para>
@ -75,11 +75,11 @@ much time is wasted.</para>
the tools in one location are hard linked to the other. An important facet of the tools in one location are hard linked to the other. An important facet of
the linker is its library search order. Detailed information can be obtained the linker is its library search order. Detailed information can be obtained
from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis> from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis>
flag. For example: <userinput>`ld --verbose | grep SEARCH`</userinput> will flag. For example: <userinput>'ld --verbose | grep SEARCH'</userinput> will
show you the current search paths and their order. You can see what files are show you the current search paths and their order. You can see what files are
actually linked by <userinput>ld</userinput> by compiling a dummy program and actually linked by <userinput>ld</userinput> by compiling a dummy program and
passing the <emphasis>--verbose</emphasis> switch. For example: passing the <emphasis>--verbose</emphasis> switch. For example:
<userinput>`gcc dummy.c -Wl,--verbose 2>&amp;1 | grep succeeded`</userinput> <userinput>'gcc dummy.c -Wl,--verbose 2>&amp;1 | grep succeeded'</userinput>
will show you all the files successfully opened during the link.</para> will show you all the files successfully opened during the link.</para>
<para>The next package installed is GCC and during its run of <para>The next package installed is GCC and during its run of
@ -93,10 +93,10 @@ that GCC's configure script does not search the $PATH directories to find which
tools to use. However, during the actual operation of <userinput>gcc</userinput> tools to use. However, during the actual operation of <userinput>gcc</userinput>
itself, the same search paths are not necessarily used. You can find out which itself, the same search paths are not necessarily used. You can find out which
standard linker <userinput>gcc</userinput> will use by running: standard linker <userinput>gcc</userinput> will use by running:
<userinput>`gcc -print-prog-name=ld`</userinput>. <userinput>'gcc -print-prog-name=ld'</userinput>.
Detailed information can be obtained from <userinput>gcc</userinput> by passing Detailed information can be obtained from <userinput>gcc</userinput> by passing
it the <emphasis>-v</emphasis> flag while compiling a dummy program. For it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
example: <userinput>`gcc -v dummy.c`</userinput> will show you detailed example: <userinput>'gcc -v dummy.c'</userinput> will show you detailed
information about the preprocessor, compilation and assembly stages, including information about the preprocessor, compilation and assembly stages, including
<userinput>gcc</userinput>'s include search paths and their order.</para> <userinput>gcc</userinput>'s include search paths and their order.</para>
@ -126,7 +126,7 @@ linker in <filename class="directory">/tools/lib</filename>. This last step is
<emphasis>vital</emphasis> to the whole process. As mentioned above, a <emphasis>vital</emphasis> to the whole process. As mentioned above, a
hard-wired path to a dynamic linker is embedded into every ELF shared hard-wired path to a dynamic linker is embedded into every ELF shared
executable. You can inspect this by running: executable. You can inspect this by running:
<userinput>`readelf -l &lt;name of binary&gt; | grep interpreter`</userinput>. <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>.
By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
program compiled from here through the end of Chapter 5 will use our new program compiled from here through the end of Chapter 5 will use our new
dynamic linker in <filename class="directory">/tools/lib</filename>.</para> dynamic linker in <filename class="directory">/tools/lib</filename>.</para>

2
chapter06/gcc-inst.xml
View File

@ -70,7 +70,7 @@ compiler. To satisfy those packages, create a symlink:</para>
<screen><userinput>ln -s gcc /usr/bin/cc</userinput></screen> <screen><userinput>ln -s gcc /usr/bin/cc</userinput></screen>
<note><para>At this point it is strongly recommended to repeat the sanity check <note><para>At this point it is strongly recommended to repeat the sanity check
we performed in the previous chapter. Refer back to we performed earlier in this chapter. Refer back to
<xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results <xref linkend="ch06-adjustingtoolchain"/> and repeat the check. If the results
are wrong, then most likely you erroneously applied the GCC Specs patch from are wrong, then most likely you erroneously applied the GCC Specs patch from
Chapter 5.</para></note> Chapter 5.</para></note>

4
index.xml
View File

@ -3,8 +3,8 @@
"/usr/share/docbook/docbookx.dtd" [ "/usr/share/docbook/docbookx.dtd" [
<!ENTITY version "20031009"> <!ENTITY version "20031012">
<!ENTITY releasedate "October 9th, 2003"> <!ENTITY releasedate "October 12th, 2003">
<!ENTITY nbsp " "> <!ENTITY nbsp " ">
<!ENTITY ftp-root "ftp://ftp.linuxfromscratch.org"> <!ENTITY ftp-root "ftp://ftp.linuxfromscratch.org">