| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119 | 
							- <?xml version="1.0" encoding="ISO-8859-1"?>
 
- <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
 
-   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 
-   <!ENTITY % general-entities SYSTEM "../general.ent">
 
-   %general-entities;
 
- ]>
 
- <sect1 id="ch-tools-adjusting">
 
-   <?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>The linker, adjusted at the end of the first pass of Binutils, needs
 
-   to be renamed so that it can be properly found and used. First, backup the
 
-   original linker, then replace it with the adjusted linker. We'll also
 
-   create a link to its counterpart in <filename class="directory">
 
-   /tools/$(gcc -dumpmachine)/bin</filename>:</para>
 
- <screen><userinput>mv -v /tools/bin/{ld,ld-old}
 
- mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
 
- mv -v /tools/bin/{ld-new,ld}
 
- ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
 
-   <para>From this point onwards, everything will link only against the
 
-   libraries in <filename class="directory">/tools/lib</filename>.</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. The principle here is to find all references
 
-   to the dynamic linker file in <filename class="directory">/lib</filename>
 
-   or possibly <filename class="directory">/lib64</filename> if the host system
 
-   is 64-bit capable, and adjust them to point to the new location in
 
-   <filename class="directory">/tools</filename>.</para>
 
-   <para>For the sake of accuracy, it is recommended to use a copy-and-paste
 
-   method when issuing the following command. Be sure to visually inspect the
 
-   specs file to verify that it has properly adjusted all references to the
 
-   dynamic linker location. Refer to <xref
 
-     linkend="ch-tools-toolchaintechnotes" role=","/> for the default name
 
-   of the dynamic linker, if necessary.</para>
 
- <!-- Ampersands are needed to allow copy and paste -->
 
- <screen><userinput>gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools&@g' > \
 
-   `dirname $(gcc -print-libgcc-file-name)`/specs</userinput></screen>
 
-   <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_FIXED=`dirname $(gcc -print-libgcc-file-name)`/include-fixed &&
 
- find ${GCC_FIXED}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
 
- rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_FIXED}/*` &&
 
- unset GCC_FIXED</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>
 
- <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>
 
- <screen><computeroutput>[Requesting program interpreter:
 
-     /tools/lib/ld-linux.so.2]</computeroutput></screen>
 
-     <para>Note that <filename class="directory">/tools/lib</filename>, or
 
-     <filename class="directory">/tools/lib64</filename> for 64-bit machines
 
-     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>
 
-   </caution>
 
-   <note><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></note>
 
- </sect1>
 
 
  |