source: chapter05/adjusting.xml@ cf9080d

Last change on this file since cf9080d was cf9080d, checked in by Matthew Burgess <matthew@…>, 19 years ago

Changed the specs file seds to prevent multiple runs from affecting the file

git-svn-id: http://svn.linuxfromscratch.org/LFS/branches/gcc4/BOOK@6546 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

  • Property mode set to 100644
File size: 5.2 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
3 <!ENTITY % general-entities SYSTEM "../general.ent">
4 %general-entities;
5]>
6<sect1 id="ch-tools-adjusting">
7<title>Adjusting the Toolchain</title>
8<?dbhtml filename="adjusting.html"?>
9
10<para>Now that the temporary C libraries have been installed, all
11tools compiled in the rest of this chapter should be linked against
12these libraries. In order to accomplish this, the linker and the
13compiler's specs file need to be adjusted.</para>
14
15<para>The linker, adjusted at the end of the first pass of Binutils,
16is installed by running the following command from within the
17<filename class="directory">binutils-build</filename> directory:</para>
18
19<screen><userinput>make -C ld install</userinput></screen>
20
21<para>From this point onwards, everything will link only
22against the libraries in <filename class="directory">/tools/lib</filename>.</para>
23
24<note><para>If the earlier warning to retain the Binutils source and
25build directories from the first pass was missed, ignore the above
26command. This results in a small chance that the subsequent testing
27programs will link against libraries on the host. This is not ideal,
28but it is not a major problem. The situation is corrected when the
29second pass of Binutils is installed later.</para></note>
30
31<para>Now that the adjusted linker is installed, the Binutils build and source
32directories should be removed.</para>
33
34<para>The next task is to point GCC to the new dynamic linker. This is done by
35dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
36by default. A simple <command>sed</command> substitution then alters the
37dynamic linker that GCC will use:</para>
38
39<!-- Ampersands are needed to allow copy and paste -->
40
41<screen><userinput>SPECFILE=`gcc -print-search-dirs | head -n 1 | awk '{ print $2 "specs" }'` &amp;&amp;
42gcc -dumpspecs > $SPECFILE &amp;&amp;
43sed -i -e 's@^/lib/ld-linux.so.2@/tools&amp;@g' $SPECFILE &amp;&amp;
44unset SPECFILE</userinput></screen>
45
46<para>It is recommended that the above
47command be copy-and-pasted in order to ensure accuracy.
48Alternatively, the specs file can be edited by hand. This is done by
49replacing every occurrence of <quote>/lib/ld-linux.so.2</quote> with
50<quote>/tools/lib/ld-linux.so.2</quote></para>
51
52<para>Be sure to visually inspect the specs file in order to verify the
53intended changes have been made.</para>
54
55<important><para>If working on a platform where the name of the
56dynamic linker is something other than
57<filename class="libraryfile">ld-linux.so.2</filename>, replace
58<quote>ld-linux.so.2</quote> with the name of the platform's
59dynamic linker in the above commands. Refer back to <xref
60linkend="ch-tools-toolchaintechnotes" role=","/> if
61necessary.</para></important>
62
63<para>There is a possibility that some include files from the host system have
64found their way into GCC's private include dir. This can happen as a result of
65GCC's <quote>fixincludes</quote> process, which runs as part of the GCC build.
66This is explained in more detail later in this chapter. Run the following
67command to eliminate this possibility:</para>
68
69<screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
70
71<caution><para>At this point, it is imperative to stop and ensure that
72the basic functions (compiling and linking) of the new toolchain are
73working as expected. To perform a sanity check, run the following
74commands:</para>
75
76<screen><userinput>echo 'main(){}' &gt; dummy.c
77cc dummy.c
78readelf -l a.out | grep ': /tools'</userinput></screen>
79
80<para>If everything is working correctly, there should be no errors,
81and the output of the last command will be of the form:</para>
82
83<screen><computeroutput>[Requesting program interpreter:
84 /tools/lib/ld-linux.so.2]</computeroutput></screen>
85
86<para>Note that <filename class="directory">/tools/lib</filename>
87appears as the prefix of the dynamic linker.</para>
88
89<para>If the output is not shown as above or there was no output at
90all, then something is wrong. Investigate and retrace the steps to
91find out where the problem is and correct it. This issue must be
92resolved before continuing on. First, perform the sanity check again,
93using <command>gcc</command> instead of <command>cc</command>. If this
94works, then the <filename class="symlink">/tools/bin/cc</filename> symlink is missing.
95Revisit <xref linkend="ch-tools-gcc-pass1" role=","/> and install the symlink.
96Next, ensure that the <envar>PATH</envar> is correct. This can be checked by running
97<command>echo $PATH</command> and verifying that <filename
98class="directory">/tools/bin</filename> is at the head of the list. If
99the <envar>PATH</envar> is wrong it could mean that you are not logged in as user
100<emphasis>lfs</emphasis> or that something went wrong back in <xref
101linkend="ch-tools-settingenviron" role="."/> Another option is that something
102may have gone wrong with the specs file amendment above. In this case,
103redo the specs file amendment, being careful to copy-and-paste the
104commands.</para>
105
106<para>Once all is well, clean up the test files:</para>
107
108<screen><userinput>rm dummy.c a.out</userinput></screen>
109</caution>
110
111</sect1>
112
Note: See TracBrowser for help on using the repository browser.