[673b0d8] | 1 | <?xml version="1.0" encoding="ISO-8859-1"?>
|
---|
[81109e3] | 2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
---|
| 3 | "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
---|
[673b0d8] | 4 | <!ENTITY % general-entities SYSTEM "../general.ent">
|
---|
| 5 | %general-entities;
|
---|
| 6 | ]>
|
---|
[81109e3] | 7 |
|
---|
[673b0d8] | 8 | <sect1 id="ch-tools-adjusting">
|
---|
[81109e3] | 9 | <?dbhtml filename="adjusting.html"?>
|
---|
| 10 |
|
---|
| 11 | <title>Adjusting the Toolchain</title>
|
---|
[673b0d8] | 12 |
|
---|
[81109e3] | 13 | <para>Now that the temporary C libraries have been installed, all
|
---|
| 14 | tools compiled in the rest of this chapter should be linked against
|
---|
| 15 | these libraries. In order to accomplish this, the linker and the
|
---|
| 16 | compiler's specs file need to be adjusted.</para>
|
---|
[81fd230] | 17 |
|
---|
[81109e3] | 18 | <para>The linker, adjusted at the end of the first pass of Binutils,
|
---|
| 19 | is installed by running the following command from within the
|
---|
| 20 | <filename class="directory">binutils-build</filename> directory:</para>
|
---|
[673b0d8] | 21 |
|
---|
| 22 | <screen><userinput>make -C ld install</userinput></screen>
|
---|
| 23 |
|
---|
[81109e3] | 24 | <para>From this point onwards, everything will link only against the
|
---|
| 25 | libraries in <filename class="directory">/tools/lib</filename>.</para>
|
---|
[81fd230] | 26 |
|
---|
[81109e3] | 27 | <note>
|
---|
| 28 | <para>If the earlier warning to retain the Binutils source and
|
---|
| 29 | build directories from the first pass was missed, ignore the above
|
---|
| 30 | command. This results in a small chance that the subsequent testing
|
---|
| 31 | programs will link against libraries on the host. This is not ideal,
|
---|
| 32 | but it is not a major problem. The situation is corrected when the
|
---|
| 33 | second pass of Binutils is installed later.</para>
|
---|
| 34 | </note>
|
---|
[81fd230] | 35 |
|
---|
[81109e3] | 36 | <para>Now that the adjusted linker is installed, the Binutils build and source
|
---|
| 37 | directories should be removed.</para>
|
---|
[81fd230] | 38 |
|
---|
[81109e3] | 39 | <para>The next task is to point GCC to the new dynamic linker. This is done by
|
---|
| 40 | dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
|
---|
| 41 | by default. A simple <command>sed</command> substitution then alters the
|
---|
| 42 | dynamic linker that GCC will use:</para>
|
---|
[81fd230] | 43 |
|
---|
| 44 | <!-- Ampersands are needed to allow copy and paste -->
|
---|
[2e02c35] | 45 | <screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &&
|
---|
| 46 | gcc -dumpspecs > $SPECFILE &&
|
---|
| 47 | sed 's@^/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile &&
|
---|
[5998892] | 48 | mv -vf tempspecfile $SPECFILE &&
|
---|
[673b0d8] | 49 | unset SPECFILE</userinput></screen>
|
---|
| 50 |
|
---|
[81109e3] | 51 | <para>It is recommended that the above command be copy-and-pasted in order to
|
---|
| 52 | ensure accuracy. Alternatively, the specs file can be edited by hand. This is
|
---|
| 53 | done by replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with
|
---|
| 54 | <quote>/tools/lib/ld-linux.so.2</quote></para>
|
---|
| 55 |
|
---|
| 56 | <para>Be sure to visually inspect the specs file in order to verify the
|
---|
| 57 | intended changes have been made.</para>
|
---|
| 58 |
|
---|
| 59 | <important>
|
---|
| 60 | <para>If working on a platform where the name of the dynamic linker is
|
---|
| 61 | something other than <filename class="libraryfile">ld-linux.so.2</filename>,
|
---|
| 62 | replace <quote>ld-linux.so.2</quote> with the name of the platform's
|
---|
| 63 | dynamic linker in the above commands. Refer back to <xref
|
---|
| 64 | linkend="ch-tools-toolchaintechnotes" role=","/> if necessary.</para>
|
---|
| 65 | </important>
|
---|
| 66 |
|
---|
| 67 | <para>During the build process, GCC runs a script
|
---|
| 68 | (<command>fixincludes</command>) that scans the system for header files
|
---|
| 69 | that may need to be fixed (they might contain syntax errors, for example),
|
---|
| 70 | and installs the fixed versions in a private include directory. There is a
|
---|
| 71 | possibility that, as a result of this process, some header files from the
|
---|
| 72 | host system have found their way into GCC's private include directory. As
|
---|
| 73 | the rest of this chapter only requires the headers from GCC and Glibc,
|
---|
| 74 | which have both been installed at this point, any <quote>fixed</quote>
|
---|
| 75 | headers can safely be removed. This helps to avoid any host headers
|
---|
| 76 | polluting the build environment. Run the following commands to remove the
|
---|
| 77 | header files in GCC's private include directory (you may find it easier to
|
---|
| 78 | copy and paste these commands, rather than typing them by hand, due to
|
---|
| 79 | their length):</para>
|
---|
[3d36131c] | 80 |
|
---|
[2e02c35] | 81 | <!-- && used to ease copy and pasting -->
|
---|
| 82 | <screen><userinput>GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
|
---|
[feaa22c] | 83 | find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
|
---|
[5998892] | 84 | rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &&
|
---|
[2e02c35] | 85 | unset GCC_INCLUDEDIR</userinput></screen>
|
---|
[673b0d8] | 86 |
|
---|
[81109e3] | 87 | <caution>
|
---|
| 88 | <para>At this point, it is imperative to stop and ensure that the basic
|
---|
| 89 | functions (compiling and linking) of the new toolchain are working as
|
---|
| 90 | expected. To perform a sanity check, run the following commands:</para>
|
---|
[fba1478] | 91 |
|
---|
[673b0d8] | 92 | <screen><userinput>echo 'main(){}' > dummy.c
|
---|
| 93 | cc dummy.c
|
---|
| 94 | readelf -l a.out | grep ': /tools'</userinput></screen>
|
---|
| 95 |
|
---|
[81109e3] | 96 | <para>If everything is working correctly, there should be no errors,
|
---|
| 97 | and the output of the last command will be of the form:</para>
|
---|
[673b0d8] | 98 |
|
---|
[81109e3] | 99 | <screen><computeroutput>[Requesting program interpreter:
|
---|
[d72e04a] | 100 | /tools/lib/ld-linux.so.2]</computeroutput></screen>
|
---|
[673b0d8] | 101 |
|
---|
[81109e3] | 102 | <para>Note that <filename class="directory">/tools/lib</filename>
|
---|
| 103 | appears as the prefix of the dynamic linker.</para>
|
---|
| 104 |
|
---|
| 105 | <para>If the output is not shown as above or there was no output at all,
|
---|
| 106 | then something is wrong. Investigate and retrace the steps to find out
|
---|
| 107 | where the problem is and correct it. This issue must be resolved before
|
---|
| 108 | continuing on. First, perform the sanity check again, using
|
---|
| 109 | <command>gcc</command> instead of <command>cc</command>. If this works,
|
---|
| 110 | then the <filename class="symlink">/tools/bin/cc</filename> symlink is
|
---|
| 111 | missing. Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install
|
---|
| 112 | the symlink. Next, ensure that the <envar>PATH</envar> is correct. This
|
---|
| 113 | can be checked by running <command>echo $PATH</command> and verifying that
|
---|
| 114 | <filename class="directory">/tools/bin</filename> is at the head of the
|
---|
| 115 | list. If the <envar>PATH</envar> is wrong it could mean that you are not
|
---|
| 116 | logged in as user <systemitem class="username">lfs</systemitem> or that
|
---|
| 117 | something went wrong back in <xref linkend="ch-tools-settingenviron"
|
---|
| 118 | role="."/> Another option is that something may have gone wrong with the
|
---|
| 119 | specs file amendment above. In this case, redo the specs file amendment,
|
---|
| 120 | being careful to copy-and-paste the commands.</para>
|
---|
| 121 |
|
---|
| 122 | <para>Once all is well, clean up the test files:</para>
|
---|
[81fd230] | 123 |
|
---|
[5998892] | 124 | <screen><userinput>rm -v dummy.c a.out</userinput></screen>
|
---|
[05d80ab8] | 125 |
|
---|
[81109e3] | 126 | <para>Building TCL in the next section will serve as an additional check that
|
---|
| 127 | the toolchain has been built properly. If TCL fails to build, it is an
|
---|
| 128 | indication that something has gone wrong with the Binutils, GCC, or Glibc
|
---|
| 129 | installation, but not with TCL itself.</para>
|
---|
| 130 | </caution>
|
---|
[673b0d8] | 131 |
|
---|
| 132 | </sect1>
|
---|