* Merged newxml into HEAD

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

1 files changed, 101 insertions, 0 deletions

diff --git a/chapter06/readjusting.xml b/chapter06/readjusting.xml
new file mode 100644
index 000000000..48efb8805
--- /dev/null
+++ b/chapter06/readjusting.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+  <!ENTITY % general-entities SYSTEM "../general.ent">
+  %general-entities;
+]>
+<sect1 id="ch-system-readjusting">
+<title>Re-adjusting the toolchain</title>
+<?dbhtml filename="readjusting.html"?>
+
+<para>Now that the new and final C libraries have been installed, it's time to
+adjust our toolchain again. We'll adjust it so that it will link any newly
+compiled program against these new libraries. This is in fact the same thing we
+did in the <quote>Adjusting</quote> phase in the beginning of the previous
+chapter, even though it looks like the reverse: then we guided the chain from
+the host's <filename class="directory">/{,usr/}lib</filename> to the new
+<filename class="directory">/tools/lib</filename>, now we guide it from that
+same <filename class="directory">/tools/lib</filename> to the LFS's <filename
+class="directory">/{,usr/}lib</filename>.</para>
+
+<para>First we adjust the linker. For this we retained the
+source and build directories from the second pass over Binutils. Install the
+adjusted linker by running the following 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 you somehow missed the earlier warning to retain the Binutils
+source and build directories from the second pass in
+<xref linkend="chapter-temporary-tools"/>, or otherwise accidentally deleted them or just
+don't have access to them, don't worry, all is not lost. Just 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, our testing has shown that the resulting Binutils program binaries
+should be identical.</para></note>
+
+<para>From now on every compiled program will link <emphasis>only</emphasis>
+against the libraries in <filename>/usr/lib</filename> and
+<filename>/lib</filename>. The extra
+<emphasis>INSTALL=/tools/bin/install</emphasis> is needed because the Makefile
+created during the second pass still contains the reference to
+<filename>/usr/bin/install</filename>, which we obviously haven't installed yet.
+Some host distributions contain a <filename class="symlink">ginstall</filename>
+symbolic link which takes precedence in the Makefile and thus can cause a
+problem here. The above command takes care of this also.</para>
+
+<para>You can now remove the Binutils source and build directories.</para>
+
+<para>The next thing to do is to amend our GCC specs file so that it points
+to the new dynamic linker. Just like earlier on, we use a sed to accomplish
+this:</para>
+
+<!-- Ampersands are needed to allow cut and paste -->
+
+<screen><userinput>SPECFILE=/tools/lib/gcc-lib/*/*/specs &amp;&amp;
+sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
+    $SPECFILE &gt; newspecfile &amp;&amp;
+mv -f newspecfile $SPECFILE &amp;&amp;
+unset SPECFILE</userinput></screen>
+
+<para>Again, cutting and pasting the above is recommended. And just like
+before, it is a good idea to visually inspect the specs file to verify the
+intended change was actually made.</para>
+
+<important><para>If you are working on a platform where the name of the dynamic
+linker is something other than <filename>ld-linux.so.2</filename>, you
+<emphasis>must</emphasis> substitute <filename>ld-linux.so.2</filename> with the
+name of your platform's dynamic linker in the above commands. Refer back to
+<xref linkend="ch-tools-toolchaintechnotes"/> if necessary.</para></important>
+
+
+<caution><para>It is imperative at this point to stop and ensure that the
+basic functions (compiling and linking) of the adjusted toolchain are working
+as expected. For this we are going to perform a simple sanity check:</para>
+
+<screen><userinput>echo 'main(){}' &gt; dummy.c
+cc dummy.c
+readelf -l a.out | grep ': /lib'</userinput></screen>
+
+<para>If everything is working correctly, there should be no errors, and the
+output of the last command will be (allowing for platform specific differences
+in dynamic linker name):</para>
+
+<blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
+
+<para>Note especially that <filename class="directory">/lib</filename> is now
+the prefix of our dynamic linker.</para>
+
+<para> If you did not receive the output
+as shown above, or received no output at all, then something is seriously wrong.
+You will need to investigate and retrace your steps to find out where the
+problem is and correct it. There is no point in continuing until this is done.
+Most likely something went wrong with the specs file amendment above.</para>
+
+<para>Once you are satisfied that all is well, clean up the test files:</para>
+
+<screen><userinput>rm dummy.c a.out</userinput></screen>
+</caution>
+
+
+</sect1>