adjusting.xml 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  1. <?xml version="1.0" encoding="ISO-8859-1"?>
  2. <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  3. "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  4. <!ENTITY % general-entities SYSTEM "../general.ent">
  5. %general-entities;
  6. ]>
  7. <sect1 id="ch-tools-adjusting">
  8. <?dbhtml filename="adjusting.html"?>
  9. <title>Adjusting the Toolchain</title>
  10. <para>Now that the temporary C libraries have been installed, all
  11. tools compiled in the rest of this chapter should be linked against
  12. these libraries. In order to accomplish this, the linker and the
  13. compiler's specs file need to be adjusted.</para>
  14. <para>The linker, adjusted at the end of the first pass of Binutils, needs
  15. to be renamed so that it can be properly found and used. First, backup the
  16. original linker, then replace it with the adjusted linker. We'll also
  17. create a link to its counterpart in <filename class="directory">
  18. /tools/$(gcc -dumpmachine)/bin</filename>:</para>
  19. <screen><userinput>mv -v /tools/bin/{ld,ld-old}
  20. mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
  21. mv -v /tools/bin/{ld-new,ld}
  22. ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
  23. <para>From this point onwards, everything will link only against the
  24. libraries in <filename class="directory">/tools/lib</filename>.</para>
  25. <para>The next task is to point GCC to the new dynamic linker. This is done by
  26. dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
  27. by default. A simple <command>sed</command> substitution then alters the
  28. dynamic linker that GCC will use. The principle here is to find all references
  29. to the dynamic linker file in <filename class="directory">/lib</filename>
  30. or possibly <filename class="directory">/lib64</filename> if the host system
  31. is 64-bit capable, and adjust them to point to the new location in
  32. <filename class="directory">/tools</filename>.</para>
  33. <para>For the sake of accuracy, it is recommended to use a copy-and-paste
  34. method when issuing the following command. Be sure to visually inspect the
  35. specs file to verify that it has properly adjusted all references to the
  36. dynamic linker location. Refer to <xref
  37. linkend="ch-tools-toolchaintechnotes" role=","/> for the default name
  38. of the dynamic linker, if necessary.</para>
  39. <!-- Ampersands are needed to allow copy and paste -->
  40. <screen><userinput>gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools&amp;@g' &gt; \
  41. `dirname $(gcc -print-libgcc-file-name)`/specs</userinput></screen>
  42. <para>During the build process, GCC runs a script
  43. (<command>fixincludes</command>) that scans the system for header files
  44. that may need to be fixed (they might contain syntax errors, for example),
  45. and installs the fixed versions in a private include directory. There is a
  46. possibility that, as a result of this process, some header files from the
  47. host system have found their way into GCC's private include directory. As
  48. the rest of this chapter only requires the headers from GCC and Glibc,
  49. which have both been installed at this point, any <quote>fixed</quote>
  50. headers can safely be removed. This helps to avoid any host headers
  51. polluting the build environment. Run the following commands to remove the
  52. header files in GCC's private include directory (you may find it easier to
  53. copy and paste these commands, rather than typing them by hand, due to
  54. their length):</para>
  55. <!-- && used to ease copy and pasting -->
  56. <screen><userinput>GCC_FIXED=`dirname $(gcc -print-libgcc-file-name)`/include-fixed &amp;&amp;
  57. find ${GCC_FIXED}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &amp;&amp;
  58. rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_FIXED}/*` &amp;&amp;
  59. unset GCC_FIXED</userinput></screen>
  60. <caution>
  61. <para>At this point, it is imperative to stop and ensure that the basic
  62. functions (compiling and linking) of the new toolchain are working as
  63. expected. To perform a sanity check, run the following commands:</para>
  64. <screen><userinput>echo 'main(){}' &gt; dummy.c
  65. cc dummy.c
  66. readelf -l a.out | grep ': /tools'</userinput></screen>
  67. <para>If everything is working correctly, there should be no errors,
  68. and the output of the last command will be of the form:</para>
  69. <screen><computeroutput>[Requesting program interpreter:
  70. /tools/lib/ld-linux.so.2]</computeroutput></screen>
  71. <para>Note that <filename class="directory">/tools/lib</filename>, or
  72. <filename class="directory">/tools/lib64</filename> for 64-bit machines
  73. appears as the prefix of the dynamic linker.</para>
  74. <para>If the output is not shown as above or there was no output at all,
  75. then something is wrong. Investigate and retrace the steps to find out
  76. where the problem is and correct it. This issue must be resolved before
  77. continuing on. First, perform the sanity check again, using
  78. <command>gcc</command> instead of <command>cc</command>. If this works,
  79. then the <filename class="symlink">/tools/bin/cc</filename> symlink is
  80. missing. Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install
  81. the symlink. Next, ensure that the <envar>PATH</envar> is correct. This
  82. can be checked by running <command>echo $PATH</command> and verifying that
  83. <filename class="directory">/tools/bin</filename> is at the head of the
  84. list. If the <envar>PATH</envar> is wrong it could mean that you are not
  85. logged in as user <systemitem class="username">lfs</systemitem> or that
  86. something went wrong back in <xref linkend="ch-tools-settingenviron"
  87. role="."/> Another option is that something may have gone wrong with the
  88. specs file amendment above. In this case, redo the specs file amendment,
  89. being careful to copy-and-paste the commands.</para>
  90. <para>Once all is well, clean up the test files:</para>
  91. <screen><userinput>rm -v dummy.c a.out</userinput></screen>
  92. </caution>
  93. <note><para>Building Tcl in the next section will serve as an additional check that
  94. the toolchain has been built properly. If Tcl fails to build, it is an
  95. indication that something has gone wrong with the Binutils, GCC, or Glibc
  96. installation, but not with Tcl itself.</para></note>
  97. </sect1>