source: chapter05/adjusting.xml@ 1375d26

Last change on this file since 1375d26 was 1375d26, checked in by Matthew Burgess <matthew@…>, 20 years ago
  • (chapter05/*.xml) RELAX NG validation fixes

git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/LFS-RNG/BOOK@4385 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

  • Property mode set to 100644
File size: 5.3 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE section [
3 <!ENTITY % general-entities SYSTEM "../general.ent">
4 %general-entities;
5]>
6<section xmlns="http://docbook.org/docbook-ng"
7 xml:id="ch-tools-adjusting">
8<title>Adjusting the toolchain</title>
9<?dbhtml filename="adjusting.html"?>
10
11<para>Now that the temporary C libraries have been installed, all
12the tools compiled in the rest of this chapter should be linked against these
13libraries. In order to accomplish this, the linker and the compiler's
14specs file, need to be adjsted.</para>
15
16<para> Some people would say that there is <emphasis><quote>black magic juju
17below this line</quote></emphasis>, but it is really very simple.</para>
18
19<para>First, the linker, adjusted at the end of the first pass of Binutils, is
20installed by running the following command from within
21the <filename class="directory">binutils-build</filename> directory:</para>
22
23<screen><userinput>make -C ld install</userinput></screen>
24
25<para>From this point onwards everything will link <emphasis>only</emphasis>
26against the libraries in <filename class="directory">/tools/lib</filename>.</para>
27
28<note><para>If you missed the earlier warning to retain the Binutils
29source and build directories from the first pass, dont worry - all is not lost.
30Just ignore the above command. This results in a small chance of the subsequent
31testing programs linking against libraries on the host. This is not ideal, but
32it's not a major problem. The situation is corrected when the second pass of
33Binutils is installed later on.</para></note>
34
35<para>Now that the adjusted linker is installed, the Binutils build and source
36directories should be <emphasis>removed</emphasis>.</para>
37
38<para>The next task is to amend our GCC specs file so that it points
39to the new dynamic linker. A simple sed script will accomplish this:</para>
40
41<!-- Ampersands are needed to allow cut and paste -->
42
43<screen><userinput>SPECFILE=`gcc --print-file specs` &amp;&amp;
44sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
45 $SPECFILE &gt; tempspecfile &amp;&amp;
46mv -f tempspecfile $SPECFILE &amp;&amp;
47unset SPECFILE</userinput></screen>
48
49<para>It is recommended that the above command be cut-and-pasted in order to
50ensure correctness - Alternatively, the specs file can be edited by hand. This
51is done simply by replacing every occurrence of
52<quote>/lib/ld-linux.so.2</quote> with <quote>/tools/lib/ld-linux.so.2</quote>.
53</para>
54
55<para> Be sure to visually inspect the specs file in order to verify the intended changes have been made.</para>
56
57<important><para>If you are working on a platform where the name of the dynamic
58linker is something other than <filename>ld-linux.so.2</filename>, you
59<emphasis>must</emphasis> replace <filename>ld-linux.so.2</filename> with the
60name of your platform's dynamic linker in the above commands. Refer back to
61<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
62
63<para>Lastly, there is a possibility that some include files from the host
64system have found their way into GCC's private include dir. This can happen
65as a result of of GCC's <quote>fixincludes</quote> process which runs as part
66of the GCC build. We'll explain more about this further on in this chapter.
67Run the following commands to eliminate this possibility:</para>
68
69<screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
70
71
72<caution><para>It is imperative at this point to stop and ensure that the basic
73functions (compiling and linking) of the new toolchain are working as expected.
74To perform a simple sanity check, run the following commands:</para>
75
76<screen><userinput>echo 'main(){}' &gt; dummy.c
77cc dummy.c
78readelf -l a.out | grep ': /tools'</userinput></screen>
79
80<para>If everything is working correctly, there should be no errors, and the
81output of the last command will be of the form:</para>
82
83<blockquote><screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen></blockquote>
84
85<para>Note especially that <filename class="directory">/tools/lib</filename>
86appears as the prefix of our dynamic linker.</para>
87
88<para>If the output is not
89as shown above, or there was no output at all, then something is seriously
90wrong. You will need to investigate and retrace your steps to find out where the
91problem is and correct it. There is no point in continuing until this is done.
92First, perform the sanity check again, using <command>gcc</command> instead of
93<command>cc</command>. If this works, then the
94<filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit
95<xref linkend="ch-tools-gcc-pass1"/> and install the symlink. Second, ensure your PATH
96is correct. You can check this by running <userinput>echo $PATH</userinput> and
97verifying that <filename class="directory">/tools/bin</filename> is at the head
98of the list. If the PATH is wrong it could mean you're not logged in as user
99<emphasis>lfs</emphasis> or something went wrong back in
100<xref linkend="ch-tools-settingenviron"/>. Third, something may have gone wrong with
101the specs file amendment above. In this case redo the specs file amendment
102being careful to cut-and-paste the commands.</para>
103
104<para>Once you are satisfied that all is well, clean up the test files:</para>
105
106<screen><userinput>rm dummy.c a.out</userinput></screen>
107</caution>
108
109
110</section>
Note: See TracBrowser for help on using the repository browser.