source: chapter05/adjusting.xml@ 5bc82c5

10.0 10.0-rc1 10.1 10.1-rc1 11.0 11.0-rc1 11.0-rc2 11.0-rc3 11.1 11.1-rc1 11.2 11.2-rc1 11.3 11.3-rc1 12.0 12.0-rc1 12.1 12.1-rc1 6.3 6.4 6.5 6.6 6.7 6.8 7.0 7.1 7.2 7.3 7.4 7.5 7.5-systemd 7.6 7.6-systemd 7.7 7.7-systemd 7.8 7.8-systemd 7.9 7.9-systemd 8.0 8.1 8.2 8.3 8.4 9.0 9.1 arm bdubbs/gcc13 ml-11.0 multilib renodr/libudev-from-systemd s6-init trunk xry111/arm64 xry111/arm64-12.0 xry111/clfs-ng xry111/lfs-next xry111/loongarch xry111/loongarch-12.0 xry111/loongarch-12.1 xry111/mips64el xry111/pip3 xry111/rust-wip-20221008 xry111/update-glibc
Last change on this file since 5bc82c5 was de59949, checked in by Matthew Burgess <matthew@…>, 18 years ago

Simplified the command that adjusts GCC's specs file

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

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