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

Touched up the grammar.

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3736 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Ian Molton 2004-06-01 21:43:10 +00:00
parent fd37ef09f0
commit f904a8703f
1 changed files with 32 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
chapter05/adjusting.xml
View File

@ -7,14 +7,16 @@
<title>Adjusting the toolchain</title>
<?dbhtml filename="adjusting.html"?>
<para>Now that the temporary C libraries have been installed, we want all
the tools compiled in the rest of this chapter to be linked against these
libraries. To accomplish this, we need to adjust the linker and the compiler's
specs file. Some people would say that it is <emphasis><quote>black magic juju
<para>Now that the temporary C libraries have been installed, all
the tools compiled in the rest of this chapter should be linked against these
libraries. In order to accomplish this the linker, and the compiler's
specs file, need to be adjsted.</para>
<para> Some people would say that there is <emphasis><quote>black magic juju
below this line</quote></emphasis>, but it is really very simple.</para>
<para>First install the adjusted linker (adjusted at the end of the first pass
of Binutils) by running the following command from within
<para>First the adjusted linker is installed (adjusted at the end of the first pass
of Binutils), by running the following command from within
the <filename class="directory">binutils-build</filename> directory:</para>
<screen><userinput>make -C ld install</userinput></screen>
@ -22,19 +24,18 @@ the <filename class="directory">binutils-build</filename> directory:</para>
<para>From this point onwards everything will link <emphasis>only</emphasis>
against the libraries in <filename class="directory">/tools/lib</filename>.</para>
<note><para>If you somehow missed the earlier warning to retain the Binutils
source and build directories from the first pass or otherwise accidentally
deleted them or just don't have access to them, don't worry, all is not lost.
Just ignore the above command. The result is a small chance of the subsequent
<note><para>If you missed the earlier warning to retain the Binutils
source and build directories from the first pass, dont worry - all is not lost.
Just ignore the above command. This results in a small chance of the subsequent
testing programs linking against libraries on the host. This is not ideal, but
it's not a major problem. The situation is corrected when we install the
second pass of Binutils a bit further on.</para></note>
it's not a major problem. The situation is corrected when the second pass of
Binutils is installed later on.</para></note>
<para>Now that the adjusted linker is installed, you have to
<emphasis>remove</emphasis> the Binutils build and source directories.</para>
<para>Now that the adjusted linker is installed, the Binutils build and source
direcotries should be <emphasis>removed</emphasis>.</para>
<para>The next 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>The next task is to amend our GCC specs file so that it points
to the new dynamic linker. A simple sed script will accomplish this:</para>
<!-- Ampersands are needed to allow cut and paste -->
@ -44,11 +45,9 @@ sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
mv -f tempspecfile $SPECFILE &amp;&amp;
unset SPECFILE</userinput></screen>
<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 the
occurrence of <quote>/lib/ld-linux.so.2</quote> with
<quote>/tools/lib/ld-linux.so.2</quote>. Be sure to visually inspect the specs
file to verify the intended change was actually made.</para>
<para>It is recommended that the above command be cut-and-pasted in order to ensure correctness - Alternatively the specs file can be edited by hand. This is done simply by replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with <quote>/tools/lib/ld-linux.so.2</quote>.</para>
<para> Be sure to visually inspect the specs file in order to verify the intended changes have been mande.</para>
<important><para>If you are working on a platform where the name of the dynamic
linker is something other than <filename>ld-linux.so.2</filename>, you
@ -58,45 +57,44 @@ name of your platform's dynamic linker in the above commands. Refer back to
<para>Lastly, there is a possibility that some include files from the host
system have found their way into GCC's private include dir. This can happen
because of GCC's <quote>fixincludes</quote> process which runs as part of the
GCC build. We'll explain more about this further on in this chapter. For now,
run the following commands to eliminate this possibility:</para>
as a result of of GCC's <quote>fixincludes</quote> process which runs as part
of the GCC build. We'll explain more about this further on in this chapter.
Run the following commands to eliminate this possibility:</para>
<screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
<caution><para>It is imperative at this point to stop and ensure that the basic
functions (compiling and linking) of the new toolchain are working as expected.
For this we are going to perform a simple sanity check:</para>
To perform a simple sanity check run the following commands:</para>
<screen><userinput>echo 'main(){}' &gt; dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'</userinput></screen>
<para>If everything is working correctly, there should be no errors, and the
output of the last command will be (allowing for platform specific differences
in dynamic linker name):</para>
output of the last command will be of the form:</para>
<blockquote><screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen></blockquote>
<para>Note especially that <filename class="directory">/tools/lib</filename>
appears as the prefix of our dynamic linker.</para>
<para>If you did not receive the output
as shown above, or received no output at all, then something is seriously wrong.
You will need to investigate and retrace your steps to find out where the
<para>If the output is not
as shown above, or there was no output at all, then something is seriously
wrong. You will need to investigate and retrace your steps to find out where the
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
First, perform the sanity check again, using <command>gcc</command> instead of
<command>cc</command>. If this works then 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 install 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
<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
ensuring to cut-and-paste the commands as was recommended.</para>
being careful to cut-and-paste the commands.</para>
<para>Once you are satisfied that all is well, clean up the test files:</para>