diff options
Diffstat (limited to 'chapter05/adjusting.xml')
| -rw-r--r-- | chapter05/adjusting.xml | 179 |
1 files changed, 91 insertions, 88 deletions
diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml index b97669497..b48a17128 100644 --- a/chapter05/adjusting.xml +++ b/chapter05/adjusting.xml @@ -1,78 +1,82 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ +<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ <!ENTITY % general-entities SYSTEM "../general.ent"> %general-entities; ]> + <sect1 id="ch-tools-adjusting"> -<title>Adjusting the Toolchain</title> -<?dbhtml filename="adjusting.html"?> + <?dbhtml filename="adjusting.html"?> + + <title>Adjusting the Toolchain</title> -<para>Now that the temporary C libraries have been installed, all -tools compiled in the rest of this chapter should be linked against -these libraries. In order to accomplish this, the linker and the -compiler's specs file need to be adjusted.</para> + <para>Now that the temporary C libraries have been installed, all + tools compiled in the rest of this chapter should be linked against + these libraries. In order to accomplish this, the linker and the + compiler's specs file need to be adjusted.</para> -<para>The linker, adjusted at the end of the first pass of Binutils, -is installed by running the following command from within the -<filename class="directory">binutils-build</filename> directory:</para> + <para>The linker, adjusted at the end of the first pass of Binutils, + is installed by running the following command from within the + <filename class="directory">binutils-build</filename> directory:</para> <screen><userinput>make -C ld install</userinput></screen> -<para>From this point onwards, everything will link only -against the libraries in <filename class="directory">/tools/lib</filename>.</para> + <para>From this point onwards, everything will link only against the + libraries in <filename class="directory">/tools/lib</filename>.</para> -<note><para>If the earlier warning to retain the Binutils source and -build directories from the first pass was missed, ignore the above -command. This results in a small chance that the subsequent testing -programs will link against libraries on the host. This is not ideal, -but it is not a major problem. The situation is corrected when the -second pass of Binutils is installed later.</para></note> + <note> + <para>If the earlier warning to retain the Binutils source and + build directories from the first pass was missed, ignore the above + command. This results in a small chance that the subsequent testing + programs will link against libraries on the host. This is not ideal, + but it is not a major problem. The situation is corrected when the + second pass of Binutils is installed later.</para> + </note> -<para>Now that the adjusted linker is installed, the Binutils build and source -directories should be removed.</para> + <para>Now that the adjusted linker is installed, the Binutils build and source + directories should be removed.</para> -<para>The next task is to point GCC to the new dynamic linker. This is done by -dumping GCC's <quote>specs</quote> file to a location where GCC will look for it -by default. A simple <command>sed</command> substitution then alters the -dynamic linker that GCC will use:</para> + <para>The next task is to point GCC to the new dynamic linker. This is done by + dumping GCC's <quote>specs</quote> file to a location where GCC will look for it + by default. A simple <command>sed</command> substitution then alters the + dynamic linker that GCC will use:</para> <!-- Ampersands are needed to allow copy and paste --> - <screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs && gcc -dumpspecs > $SPECFILE && sed 's@^/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile && mv -vf tempspecfile $SPECFILE && unset SPECFILE</userinput></screen> -<para>It is recommended that the above -command be copy-and-pasted in order to ensure accuracy. -Alternatively, the specs file can be edited by hand. This is done by -replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with -<quote>/tools/lib/ld-linux.so.2</quote></para> - -<para>Be sure to visually inspect the specs file in order to verify the -intended changes have been made.</para> - -<important><para>If working on a platform where the name of the -dynamic linker is something other than -<filename class="libraryfile">ld-linux.so.2</filename>, replace -<quote>ld-linux.so.2</quote> with the name of the platform's -dynamic linker in the above commands. Refer back to <xref -linkend="ch-tools-toolchaintechnotes" role=","/> if -necessary.</para></important> - -<para>During the build process, GCC runs a script -(<command>fixincludes</command>) that scans the system for header files that may -need to be fixed (they might contain syntax errors, for example), and installs -the fixed versions in a private include directory. There is a possibility that, -as a result of this process, some header files from the host system have found -their way into GCC's private include directory. As the rest of this chapter only -requires the headers from GCC and Glibc, which have both been installed at this -point, any "fixed" headers can safely be removed. This helps to avoid -any host headers polluting the build environment. Run the following commands to -remove the header files in GCC's private include directory (you may find it -easier to copy and paste these commands, rather than typing them by hand, due to -their length):</para> + <para>It is recommended that the above command be copy-and-pasted in order to + ensure accuracy. Alternatively, the specs file can be edited by hand. This is + done by replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with + <quote>/tools/lib/ld-linux.so.2</quote></para> + + <para>Be sure to visually inspect the specs file in order to verify the + intended changes have been made.</para> + + <important> + <para>If working on a platform where the name of the dynamic linker is + something other than <filename class="libraryfile">ld-linux.so.2</filename>, + replace <quote>ld-linux.so.2</quote> with the name of the platform's + dynamic linker in the above commands. Refer back to <xref + linkend="ch-tools-toolchaintechnotes" role=","/> if necessary.</para> + </important> + + <para>During the build process, GCC runs a script + (<command>fixincludes</command>) that scans the system for header files + that may need to be fixed (they might contain syntax errors, for example), + and installs the fixed versions in a private include directory. There is a + possibility that, as a result of this process, some header files from the + host system have found their way into GCC's private include directory. As + the rest of this chapter only requires the headers from GCC and Glibc, + which have both been installed at this point, any <quote>fixed</quote> + headers can safely be removed. This helps to avoid any host headers + polluting the build environment. Run the following commands to remove the + header files in GCC's private include directory (you may find it easier to + copy and paste these commands, rather than typing them by hand, due to + their length):</para> <!-- && used to ease copy and pasting --> <screen><userinput>GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include && @@ -80,50 +84,49 @@ find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; && rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` && unset GCC_INCLUDEDIR</userinput></screen> -<caution><para>At this point, it is imperative to stop and ensure that -the basic functions (compiling and linking) of the new toolchain are -working as expected. To perform a sanity check, run the following -commands:</para> + <caution> + <para>At this point, it is imperative to stop and ensure that the basic + functions (compiling and linking) of the new toolchain are working as + expected. To perform a sanity check, run the following commands:</para> <screen><userinput>echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /tools'</userinput></screen> -<para>If everything is working correctly, there should be no errors, -and the output of the last command will be of the form:</para> + <para>If everything is working correctly, there should be no errors, + and the output of the last command will be of the form:</para> -<screen><computeroutput>[Requesting program interpreter: +<screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen> -<para>Note that <filename class="directory">/tools/lib</filename> -appears as the prefix of the dynamic linker.</para> - -<para>If the output is not shown as above or there was no output at -all, then something is wrong. Investigate and retrace the steps to -find out where the problem is and correct it. This issue must be -resolved before continuing on. First, perform the sanity check again, -using <command>gcc</command> instead of <command>cc</command>. If this -works, then the <filename class="symlink">/tools/bin/cc</filename> symlink is missing. -Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install the symlink. -Next, ensure that the <envar>PATH</envar> is correct. This can be checked by running -<command>echo $PATH</command> and verifying that <filename -class="directory">/tools/bin</filename> is at the head of the list. If -the <envar>PATH</envar> is wrong it could mean that you are not logged in as user -<emphasis>lfs</emphasis> or that something went wrong back in <xref -linkend="ch-tools-settingenviron" role="."/> Another option is that something -may have gone wrong with the specs file amendment above. In this case, -redo the specs file amendment, being careful to copy-and-paste the -commands.</para> - -<para>Once all is well, clean up the test files:</para> + <para>Note that <filename class="directory">/tools/lib</filename> + appears as the prefix of the dynamic linker.</para> + + <para>If the output is not shown as above or there was no output at all, + then something is wrong. Investigate and retrace the steps to find out + where the problem is and correct it. This issue must be resolved before + continuing on. First, perform the sanity check again, using + <command>gcc</command> instead of <command>cc</command>. If this works, + then the <filename class="symlink">/tools/bin/cc</filename> symlink is + missing. Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install + the symlink. Next, ensure that the <envar>PATH</envar> is correct. This + can be checked by running <command>echo $PATH</command> and verifying that + <filename class="directory">/tools/bin</filename> is at the head of the + list. If the <envar>PATH</envar> is wrong it could mean that you are not + logged in as user <systemitem class="username">lfs</systemitem> or that + something went wrong back in <xref linkend="ch-tools-settingenviron" + role="."/> Another option is that something may have gone wrong with the + specs file amendment above. In this case, redo the specs file amendment, + being careful to copy-and-paste the commands.</para> + + <para>Once all is well, clean up the test files:</para> <screen><userinput>rm -v dummy.c a.out</userinput></screen> -<para>Building TCL in the next section will serve as an additional check that -the toolchain has been built properly. If TCL fails to build, it is an -indication that something has gone wrong with the Binutils, GCC, or Glibc -installation, but not with TCL itself.</para> - -</caution> + <para>Building TCL in the next section will serve as an additional check that + the toolchain has been built properly. If TCL fails to build, it is an + indication that something has gone wrong with the Binutils, GCC, or Glibc + installation, but not with TCL itself.</para> + </caution> </sect1> |