newxml/chapter05/adjusting.xml

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