Initial addition of support for x86_64

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

7 files changed, 70 insertions, 40 deletions

diff --git a/chapter06/binutils.xml b/chapter06/binutils.xml
index aaebc6cce..cc67448d0 100644
--- a/chapter06/binutils.xml
+++ b/chapter06/binutils.xml
@@ -97,8 +97,8 @@ cd ../binutils-build</userinput></screen>
           <para>Normally, the tooldir (the directory where the executables will
           ultimately be located) is set to <filename
           class="directory">$(exec_prefix)/$(target_alias)</filename>. For
-          example, i686 machines would expand that to <filename
-          class="directory">/usr/i686-pc-linux-gnu</filename>. Because this is
+          example, x86_64 machines would expand that to <filename
+          class="directory">/usr/x86_64-unknown-linux-gnu</filename>. Because this is
           a custom system, this target-specific directory in <filename
           class="directory">/usr</filename> is not required. <filename
           class="directory">$(exec_prefix)/$(target_alias)</filename> would be
diff --git a/chapter06/coreutils.xml b/chapter06/coreutils.xml
index b045897f4..493b39593 100644
--- a/chapter06/coreutils.xml
+++ b/chapter06/coreutils.xml
@@ -46,7 +46,9 @@
     returns <computeroutput>unknown</computeroutput>. The following patch
     fixes this behavior for Intel architectures:</para>
 
-<screen><userinput remap="pre">patch -Np1 -i ../&coreutils-uname-patch;</userinput></screen>
+<screen><userinput remap="pre">case `uname -m` in
+ i?86 | x86_64) patch -Np1 -i ../&coreutils-uname-patch; ;;
+esac</userinput></screen>
 
     <para>There's an internal issue with Coreutils which makes some of the
     programs behave abnormally if you build using an older kernel. Apply a
diff --git a/chapter06/creatingdirs.xml b/chapter06/creatingdirs.xml
index 1a2783916..382b1e504 100644
--- a/chapter06/creatingdirs.xml
+++ b/chapter06/creatingdirs.xml
@@ -24,6 +24,8 @@ mkdir -pv /usr/{,local/}share/man/man{1..8}
 for dir in /usr /usr/local; do
   ln -sv share/{man,doc,info} $dir
 done
+ln -sv lib /lib64
+ln -sv lib /usr/lib64
 mkdir -v /var/{lock,log,mail,run,spool}
 mkdir -pv /var/{opt,cache,lib/{misc,locate},local}</userinput></screen>
 
diff --git a/chapter06/gcc.xml b/chapter06/gcc.xml
index a01262a31..8546b670a 100644
--- a/chapter06/gcc.xml
+++ b/chapter06/gcc.xml
@@ -48,13 +48,17 @@
 
 <screen><userinput remap="pre">sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in</userinput></screen>
 
-    <para>The bootstrap build performed in <xref linkend="ch-tools-gcc-pass1"/>
+    <para>For x86 machines, the bootstrap build performed in
+    <xref linkend="ch-tools-gcc-pass2"/>
     built GCC with the <option>-fomit-frame-pointer</option> compiler flag.
     Non-bootstrap builds omit this flag by default, so apply the following
     <command>sed</command> to use it in order to ensure consistent compiler
     builds:</para>
 
-<screen><userinput remap="pre">sed -i 's/^XCFLAGS =$/&amp; -fomit-frame-pointer/' gcc/Makefile.in</userinput></screen>
+<screen><userinput remap="pre">case `uname -m` in
+  i?86) sed -i 's/^XCFLAGS =$/&amp; -fomit-frame-pointer/' \
+        gcc/Makefile.in ;;
+esac</userinput></screen>
 
     <para>The <command>fixincludes</command> script is known to occasionally
     erroneously attempt to &quot;fix&quot; the system headers installed so far. As
@@ -76,7 +80,7 @@ cd ../gcc-build</userinput></screen>
     --libexecdir=/usr/lib --enable-shared \
     --enable-threads=posix --enable-__cxa_atexit \
     --enable-clocale=gnu --enable-languages=c,c++ \
-    --disable-bootstrap</userinput></screen>
+    --disable-multilib --disable-bootstrap</userinput></screen>
 
     <para>Note that for other languages, there are some prerequsites that
     are not available.  See the BLFS Book for instructions on how to
@@ -160,6 +164,14 @@ cd ../gcc-build</userinput></screen>
 /usr/lib/gcc/i686-pc-linux-gnu/&gcc-version;/../../../crti.o succeeded
 /usr/lib/gcc/i686-pc-linux-gnu/&gcc-version;/../../../crtn.o succeeded</computeroutput></screen>
 
+  <para>Depending on your machine architecture, the above may differ slightly,
+  the difference usually being the name of the directory
+  after <filename class="directory">/usr/lib/gcc</filename>. If your machine is
+  a 64-bit system, you may also see a directory named <filename class="directory">lib64</filename>
+  towards the end of the string. The important thing to
+  look for here is that gcc has found all three <filename>crt*.o</filename> files under
+  the <filename class="directory">/usr/lib</filename> directory.</para>
+
     <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
     href="readjusting.xml"
     xpointer="xpointer(//*[@os='g'])"/>
@@ -172,10 +184,13 @@ cd ../gcc-build</userinput></screen>
 
 <screen><computeroutput>#include &lt;...&gt; search starts here:
  /usr/local/include
- /usr/lib/gcc/i686-pc-linux-gnu/&gcc-version;/include
+ /usr/lib/gcc/x86_64-unknown-linux-gnu/&gcc-version;/include
  /usr/lib/gcc/i686-pc-linux-gnu/&gcc-version;/include-fixed
  /usr/include</computeroutput></screen>
 
+   <para>Again, note that the directory named after your target triplet may be
+   different than the above, depending on your architecture.</para>
+
     <note><para>As of version 4.3.0, GCC now unconditionally installs the
     <filename>limits.h</filename> file into the private
     <filename class="directory">include-fixed</filename> directory, and that
@@ -198,6 +213,18 @@ SEARCH_DIR("/usr/local/lib")
 SEARCH_DIR("/lib")
 SEARCH_DIR("/usr/lib");</computeroutput></screen>
 
+   <para>A 64-bit system may see a few more directories. For example, here
+   is the output from a x86_64 machine:</para>
+
+<screen><computeroutput>SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
+SEARCH_DIR("/usr/local/lib64")
+SEARCH_DIR("/lib64")
+SEARCH_DIR("/usr/lib64")
+SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib")
+SEARCH_DIR("/usr/local/lib")
+SEARCH_DIR("/lib")
+SEARCH_DIR("/usr/lib");</computeroutput></screen>
+
     <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
     href="readjusting.xml"
     xpointer="xpointer(//*[@os='l'])"/>
diff --git a/chapter06/glibc.xml b/chapter06/glibc.xml
index d8aff783f..3aaa0f9d1 100644
--- a/chapter06/glibc.xml
+++ b/chapter06/glibc.xml
@@ -84,9 +84,11 @@ mv glibc-libidn-&glibc-version; libidn</userinput></screen>-->
     test would be carried out against the wrong Glibc. We can force the script
     to check the Glibc we have just installed with the following:</para>
 
-<screen><userinput remap="pre">sed -i \
-'s|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=/lib/ld-linux.so.2 -o|' \
-        scripts/test-installation.pl</userinput></screen> -->
+<screen><userinput remap="pre">DL=$(readelf -l /bin/sh | grep interpreter | \
+awk '{print $4}' | sed -e 's@/tools@@' -e 's@]$@@')
+sed -i &quot;s|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=$DL -o|&quot; \
+        scripts/test-installation.pl
+unset DL</userinput></screen> -->
 
     <para>First apply two patches which correct failures in the test
     suite:</para>
@@ -109,9 +111,11 @@ patch -Np1 -i ../&glibc-ildoubl-test-fix-patch;</userinput></screen>
 <screen><userinput remap="pre">mkdir -v ../glibc-build
 cd ../glibc-build</userinput></screen>
 
-    <para>Again, add the needed compiler flag to CFLAGS:</para>
+    <para>Again, add the needed compiler flags to CFLAGS for x86 machines:</para>
 
-<screen><userinput remap="configure">echo "CFLAGS += -march=i486 -mtune=native" &gt; configparms</userinput></screen>
+<screen><userinput remap="configure">case `uname -m` in
+  i?86) echo "CFLAGS += -march=i486 -mtune=native" &gt; configparms ;;
+esac</userinput></screen>
 
     <para>Prepare Glibc for compilation:</para>
 
diff --git a/chapter06/introduction.xml b/chapter06/introduction.xml
index 5268fb66a..291992fa4 100644
--- a/chapter06/introduction.xml
+++ b/chapter06/introduction.xml
@@ -23,20 +23,21 @@
   followed by concise descriptions of each program and library the package
   installed.</para>
 
-  <para>If using compiler optimizations, please
-  review the optimization hint at <ulink url="&hints-root;optimization.txt"/>.
-  Compiler optimizations can make a program run slightly faster, but they may
-  also cause compilation difficulties and problems when running the program.
-  If a package refuses to compile when using optimization, try to compile it
-  without optimization and see if that fixes the problem. Even if the package
-  does compile when using optimization, there is the risk it may have been
-  compiled incorrectly because of the complex interactions between the code
-  and build tools.  Also note that the <option>-march</option> and
-  <option>-mtune</option> options may cause problems with the toolchain packages
-  (Binutils, GCC and Glibc).  The small potential gains achieved in using
-  compiler optimizations are often outweighed by the risks. First-time builders
-  of LFS are encouraged to build without custom optimizations. The subsequent
-  system will still run very fast and be stable at the same time.</para>
+  <para>If using compiler optimizations, please review the optimization hint at
+  <ulink url="&hints-root;optimization.txt"/>.  Compiler optimizations can make
+  a program run slightly faster, but they may also cause compilation
+  difficulties and problems when running the program.  If a package refuses to
+  compile when using optimization, try to compile it without optimization and
+  see if that fixes the problem. Even if the package does compile when using
+  optimization, there is the risk it may have been compiled incorrectly because
+  of the complex interactions between the code and build tools.  Also note that
+  the <option>-march</option> and <option>-mtune</option> options using values
+  not specified in the book have not been tested. This may cause problems with
+  the toolchain packages (Binutils, GCC and Glibc).  The small potential gains
+  achieved in using compiler optimizations are often outweighed by the risks.
+  First-time builders of LFS are encouraged to build without custom
+  optimizations. The subsequent system will still run very fast and be stable
+  at the same time.</para>
 
   <para>The order that packages are installed in this chapter needs to be
   strictly followed to ensure that no program accidentally acquires a path
diff --git a/chapter06/readjusting.xml b/chapter06/readjusting.xml
index 83cdf298f..8bda83151 100644
--- a/chapter06/readjusting.xml
+++ b/chapter06/readjusting.xml
@@ -37,16 +37,7 @@ ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
   and Glibc start files. A <command>sed</command> command accomplishes
   this:</para>
 
-  <important>
-    <para>If working on a platform where the name of the dynamic linker is
-    something other than <filename class="libraryfile">ld-linux.so.2</filename>,
-    substitute <quote>ld-linux.so.2</quote> with the name of the platform's
-    dynamic linker in the following commands. Refer to <xref
-    linkend="ch-tools-toolchaintechnotes" role=","/> if necessary.</para>
-  </important>
-
-<screen><userinput>gcc -dumpspecs | sed \
-    -e 's@/tools/lib/ld-linux.so.2@/lib/ld-linux.so.2@g' \
+<screen><userinput>gcc -dumpspecs | sed -e 's@/tools@@g' \
     -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \
     -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' &gt; \
     `dirname $(gcc --print-libgcc-file-name)`/specs</userinput></screen>
@@ -97,7 +88,8 @@ readelf -l a.out | grep ': /lib'</userinput></screen>
 <screen os="j"><userinput>grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'</userinput></screen>
 
   <para os="k">If everything is working correctly, there should be no errors,
-  and the output of the last command will be:</para>
+  and the output of the last command (allowing for platform-specific target triplets)
+  will be:</para>
 
 <screen><computeroutput>SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
 SEARCH_DIR("/usr/lib")
@@ -105,10 +97,11 @@ SEARCH_DIR("/lib");</computeroutput></screen>
 
   <para os="l">Next make sure that we're using the correct libc:</para>
 
-<screen os="m"><userinput>grep "/lib/libc.so.6 " dummy.log</userinput></screen>
+<screen os="m"><userinput>grep "/lib.*/libc.so.6 " dummy.log</userinput></screen>
 
   <para os="n">If everything is working correctly, there should be no errors,
-  and the output of the last command will be:</para>
+  and the output of the last command (allowing for a lib64 directory on 64-bit hosts)
+  will be:</para>
 
 <screen os="o"><computeroutput>attempt to open /lib/libc.so.6 succeeded</computeroutput></screen>
 
@@ -118,7 +111,8 @@ SEARCH_DIR("/lib");</computeroutput></screen>
 
   <para os="r">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>
+  platform-specific differences in dynamic linker name and a lib64 directory
+  on 64-bit hosts):</para>
 
 <screen os="s"><computeroutput>found ld-linux.so.2 at /lib/ld-linux.so.2</computeroutput></screen>