adjustingtoolchain.xml 4.0 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
  1. <sect1 id="ch06-adjustingtoolchain">
  2. <title>Re-adjusting the toolchain</title>
  3. <?dbhtml filename="adjustingtoolchain.html" dir="chapter06"?>
  4. <para>Now that the new C libraries have been installed, it's time to re-adjust
  5. our toolchain. We'll adjust it so that it will link any newly compiled program
  6. against the new C libraries. Basically, this is the reverse of what we did
  7. in the "Locking in" stage in the beginning of the previous chapter.</para>
  8. <para>The first thing to do is to adjust the linker. For this we retained the
  9. source and build directories from the second pass over Binutils. Install the
  10. adjusted linker by running the following from within the
  11. <filename class="directory">binutils-build</filename> directory:</para>
  12. <para><screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen></para>
  13. <note><para>If you somehow missed the earlier warning to retain the Binutils
  14. source and build directories from the second pass in Chapter 5 or otherwise
  15. accidentally deleted them or just don't have access to them, don't worry, all is
  16. not lost. Just ignore this step. The result will be that the next package,
  17. Binutils, will link against the Glibc libraries in
  18. <filename class="directory">/tools</filename> rather than
  19. <filename class="directory">/usr</filename>. This is not ideal, however, our
  20. testing has shown that the resulting Binutils program binaries should be
  21. identical.</para></note>
  22. <para>From now on every compiled program will link <emphasis>only</emphasis>
  23. against the libraries in <filename>/usr/lib</filename> and
  24. <filename>/lib</filename>. The extra
  25. <userinput>INSTALL=/tools/bin/install</userinput> is needed because the Makefile
  26. created during the second pass still contains the reference to
  27. <filename>/usr/bin/install</filename>, which we obviously haven't installed yet.
  28. Some host distributions contain a <filename class="symlink">ginstall</filename>
  29. symbolic link which takes precedence in the Makefile and thus can cause a
  30. problem here. The above command takes care of this also.</para>
  31. <para>You can now remove the Binutils source and build directories.</para>
  32. <para>The next thing to do is to amend our GCC specs file so that it points
  33. to the new dynamic linker. Just like earlier on, we use a sed to accomplish
  34. this:</para>
  35. <para><screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs
  36. sed -e 's@/tools/lib/ld.so.1@/lib/ld.so.1@g' \
  37. &nbsp;&nbsp;&nbsp;&nbsp;-e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \
  38. &nbsp;&nbsp;&nbsp;&nbsp;$SPECFILE > newspecfile
  39. mv newspecfile $SPECFILE
  40. unset SPECFILE</userinput></screen></para>
  41. <para>Again, cutting and pasting the above is recommended. And just like
  42. before, it is a good idea to check the specs file to ensure the intended
  43. changes were actually made.</para>
  44. <caution><para>It is imperative at this point to stop and ensure that the
  45. basic functions (compiling and linking) of the adjusted toolchain are working
  46. as expected. For this we are going to perform a simple sanity check:</para>
  47. <para><screen><userinput>echo 'main(){}' > dummy.c
  48. gcc dummy.c
  49. readelf -l a.out | grep ': /lib'</userinput></screen></para>
  50. <para>If everything is working correctly, there should be no errors, and the
  51. output of the last command will be:</para>
  52. <blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
  53. <para>If you did not receive the output as shown above, then something is
  54. seriously wrong. You will need to investigate and retrace your steps to find
  55. out where the problem is and correct it. There is no point in continuing
  56. until this is done. Most likely something went wrong with the specs file
  57. amendment above. Note especially that <filename>/lib</filename> now appears as
  58. the prefix of our dynamic linker. Of course, if you are working on a platform
  59. where the name of the dynamic linker is something other than
  60. <filename>ld-linux.so.2</filename>, then the output will be slightly
  61. different.</para>
  62. <para>Once you are satisfied that all is well, clean up the test files:</para>
  63. <para><screen><userinput>rm dummy.c a.out</userinput></screen></para>
  64. </caution>
  65. </sect1>