Fixed the re-adjusting of the toolchain in chapter 6 so that chapter 6 GCC and Binutils links against the proper Glibc and so that we don't have to keep the binutils directories from chapter 5.

Also moved a note about saving the /tools directory to the beginning of chapter 6.
Fixes bug 1677. Thanks to Chris Staub, Alexander Patrakov, Greg Schafer and Tushar Teredesai for reporting and resolving this issue.


git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7306 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Jeremy Huntwork 2006-01-26 03:45:12 +00:00
parent ae437d3255
commit 313ca76210
6 changed files with 32 additions and 52 deletions

View File

@ -48,6 +48,14 @@
the correct Glibc. Fixes bug 1675. Thanks to Dan Nicholson for the report the correct Glibc. Fixes bug 1675. Thanks to Dan Nicholson for the report
and Greg Schafer for the fix.</para> and Greg Schafer for the fix.</para>
</listitem> </listitem>
<listitem>
<para>[jhuntwork] - Fixed the re-adjusting of the toolchain in chapter 6
so that chapter 6 GCC and Binutils links against the proper Glibc and so
that we don't have to keep the binutils directories from chapter 5. Also
moved a note about saving the /tools directory to the beginning of chapter 6.
Fixes bug 1677. Thanks to Chris Staub, Alexander Patrakov, Greg Schafer and
Tushar Teredesai for reporting and resolving this issue.</para>
</listitem>
</itemizedlist> </itemizedlist>
</listitem> </listitem>

View File

@ -82,18 +82,6 @@ cd ../binutils-build</userinput></screen>
<screen><userinput>make install</userinput></screen> <screen><userinput>make install</userinput></screen>
<para>Now prepare the linker for the <quote>Re-adjusting</quote> phase in
the next chapter:</para>
<screen><userinput>make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib</userinput></screen>
<warning>
<para><emphasis>Do not</emphasis> remove the Binutils source and build
directories yet. These directories will be needed again in the next
chapter in their current state.</para>
</warning>
</sect2> </sect2>
<sect2 role="content"> <sect2 role="content">

View File

@ -99,11 +99,6 @@ To support those packages, create this symlink:</para>
<screen><userinput>ln -sv ../usr/bin/cpp /lib</userinput></screen> <screen><userinput>ln -sv ../usr/bin/cpp /lib</userinput></screen>
<para>Many packages use the name <command>cc</command> to call the C
compiler. To satisfy those packages, create a symlink:</para>
<screen><userinput>ln -sv gcc /usr/bin/cc</userinput></screen>
<note><para>At this point, it is strongly recommended to repeat the <note><para>At this point, it is strongly recommended to repeat the
sanity check performed earlier in this chapter. Refer back to <xref sanity check performed earlier in this chapter. Refer back to <xref
linkend="ch-system-readjusting" role=","/> and repeat the check. If the results linkend="ch-system-readjusting" role=","/> and repeat the check. If the results

View File

@ -58,5 +58,10 @@ package. Following the installation instructions, there is a list of
programs and libraries (along with brief descriptions of these) that programs and libraries (along with brief descriptions of these) that
the package installs.</para> the package installs.</para>
<note><para>At this point, you may wish to keep your finished temporary
tools for use in future LFS builds by creating a tarball of the
<filename class="directory">/tools</filename> directory and
storing it in a safe location.</para></note>
</sect1> </sect1>

View File

@ -9,7 +9,7 @@
<para>Now that the final C libraries have been installed, it is time to adjust <para>Now that the final C libraries have been installed, it is time to adjust
the toolchain again. The toolchain will be adjusted so that it will link any the toolchain again. The toolchain will be adjusted so that it will link any
newly compiled program against these new libraries. This is the same process newly compiled program against these new libraries. This is a similar process
used in the <quote>Adjusting</quote> phase in the beginning of <xref used in the <quote>Adjusting</quote> phase in the beginning of <xref
linkend="chapter-temporary-tools"/>, but with the adjustments reversed. In <xref linkend="chapter-temporary-tools"/>, but with the adjustments reversed. In <xref
linkend="chapter-temporary-tools"/>, the chain was guided from the host's linkend="chapter-temporary-tools"/>, the chain was guided from the host's
@ -19,38 +19,7 @@ be guided from that same <filename class="directory">/tools/lib</filename>
directory to the LFS <filename class="directory">/{,usr/}lib</filename> directory to the LFS <filename class="directory">/{,usr/}lib</filename>
directories.</para> directories.</para>
<para>Start by adjusting the linker. The source and build directories from the <para>First, amend the GCC specs file so that it points to the new
second pass of Binutils were retained for this purpose. Install the adjusted
linker by running the following command from within the <filename
class="directory">binutils-build</filename> directory:</para>
<screen><userinput>make -C ld INSTALL=/tools/bin/install install</userinput></screen>
<note><para>If the earlier warning to retain the Binutils source and
build directories from the second pass in <xref
linkend="chapter-temporary-tools"/> was missed, or if they were
accidentally deleted or are inaccessible, ignore the above command.
The result will be that the next package, Binutils, will link against
the C libraries in <filename class="directory">/tools</filename>
rather than in <filename class="directory">/{,usr/}lib</filename>.
This is not ideal, however, testing has shown that the resulting
Binutils program binaries should be identical.</para></note>
<para>From now on, every compiled program will link only against the
libraries in <filename class="directory">/usr/lib</filename> and
<filename class="directory">/lib</filename>. The extra
<parameter>INSTALL=/tools/bin/install</parameter> option is needed
because the <filename>Makefile</filename> file created during the
second pass still contains the reference to
<command>/usr/bin/install</command>, which has not been installed yet.
Some host distributions contain a <filename
class="symlink">ginstall</filename> symbolic link which takes
precedence in the <filename>Makefile</filename> file and can cause a
problem. The above command takes care of this issue.</para>
<para>Remove the Binutils source and build directories now.</para>
<para>Next, amend the GCC specs file so that it points to the new
dynamic linker. A <command>sed</command> command accomplishes this:</para> dynamic linker. A <command>sed</command> command accomplishes this:</para>
<screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &amp;&amp; <screen><userinput>SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &amp;&amp;
@ -69,6 +38,22 @@ dynamic linker in the above commands. Refer back to <xref
linkend="ch-tools-toolchaintechnotes" role=","/> if linkend="ch-tools-toolchaintechnotes" role=","/> if
necessary.</para></important> necessary.</para></important>
<para>Now create temporary wrapper scripts for <filename>gcc</filename> and
<filename>ld</filename>. These scripts will point to their real counterparts
in <filename class="directory">/tools</filename> but with adjusted parameters
to ensure that GCC in the next section links to our newly installed Glibc.</para>
<screen><userinput>cat &gt; /usr/bin/gcc &lt;&lt; "EOF"
#!/bin/bash
/tools/bin/gcc -B/usr/lib $@
EOF
cat &gt; /usr/bin/ld &lt;&lt; "EOF"
#!/bin/bash
/tools/bin/ld -nostdlib -L/usr/lib -L/lib $@
EOF
chmod 755 /usr/bin/{ld,gcc}
ln -s gcc /usr/bin/cc</userinput></screen>
<caution><para>It is imperative at this point to stop and ensure that <caution><para>It is imperative at this point to stop and ensure that
the basic functions (compiling and linking) of the adjusted toolchain the basic functions (compiling and linking) of the adjusted toolchain
are working as expected. To do this, perform a sanity are working as expected. To do this, perform a sanity

View File

@ -18,8 +18,7 @@ exiting, use the following modified chroot command:</para>
<para>The reason for this is that the programs in <filename <para>The reason for this is that the programs in <filename
class="directory">/tools</filename> are no longer needed. Since they are no class="directory">/tools</filename> are no longer needed. Since they are no
longer needed you can delete the <filename class="directory">/tools</filename> longer needed you can delete the <filename class="directory">/tools</filename>
directory if so desired or tar it up and keep it to build another final directory if so desired.</para>
system.</para>
<note><para>Removing <filename class="directory">/tools</filename> will also <note><para>Removing <filename class="directory">/tools</filename> will also
remove the temporary copies of Tcl, Expect, and DejaGNU which were used for remove the temporary copies of Tcl, Expect, and DejaGNU which were used for