Initial addition of support for x86_64

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

chapter01/changelog.xml

@@ -36,6 +36,17 @@
     </listitem>
 
 -->
+    <listitem>
+      <para>2008-12-03</para>
+      <itemizedlist>
+        <listitem>
+          <para>[jhuntwork] - Initial addition of support for building on x86_64.
+	  Several ideas, principles and build instructions originated in DIY-Linux.
+          Thanks, Greg Schafer.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
     <listitem>
       <para>2008-12-02</para>
       <itemizedlist>

chapter05/adjusting.xml

@@ -32,23 +32,21 @@ ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
   <para>The next task is to point GCC to the new dynamic linker. This is done by
   dumping GCC's <quote>specs</quote> file to a location where GCC will look for it
   by default. A simple <command>sed</command> substitution then alters the
-  dynamic linker that GCC will use.</para>
+  dynamic linker that GCC will use. The principle here is to find all references
+  to the dynamic linker file in <filename class="directory">/lib</filename>
+  or possibly <filename class="directory">/lib64</filename> if the host system
+  is 64-bit capable, and adjust them to point to the new location in
+  <filename class="directory">/tools</filename>.</para>
 
   <para>For the sake of accuracy, it is recommended to use a copy-and-paste
   method when issuing the following command. Be sure to visually inspect the
-  specs file and verify that all occurrences of <quote>/lib/ld-linux.so.2</quote>
-  have been replaced with <quote>/tools/lib/ld-linux.so.2</quote>:</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>,
-    replace <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>
+  specs file to verify that it has properly adjusted all references to the
+  dynamic linker location. Refer to <xref
+    linkend="ch-tools-toolchaintechnotes" role=","/> for the default name
+  of the dynamic linker, if necessary.</para>
 
 <!-- Ampersands are needed to allow copy and paste -->
-<screen><userinput>gcc -dumpspecs | sed 's@/lib/ld-linux.so.2@/tools&amp;@g' &gt; \
+<screen><userinput>gcc -dumpspecs | sed 's@/lib\(64\)\?/ld@/tools&amp;@g' &gt; \
   `dirname $(gcc -print-libgcc-file-name)`/specs</userinput></screen>
 
   <para>During the build process, GCC runs a script
@@ -86,7 +84,8 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
 <screen><computeroutput>[Requesting program interpreter:
     /tools/lib/ld-linux.so.2]</computeroutput></screen>
 
-    <para>Note that <filename class="directory">/tools/lib</filename>
+    <para>Note that <filename class="directory">/tools/lib</filename>, or
+    <filename class="directory">/tools/lib64</filename> for 64-bit machines
     appears as the prefix of the dynamic linker.</para>
 
     <para>If the output is not shown as above or there was no output at all,

chapter05/binutils-pass1.xml

@@ -124,11 +124,16 @@ cd ../binutils-build</userinput></screen>
     tests at this point are minimal since the programs from this
     first pass will soon be replaced by those from the second.</para>
 
+    <para>Create a symlink to ensure the sanity of our toolchain:</para>
+
+<screen><userinput remap="install">mkdir -v /tools/lib
+ln -sv lib /tools/lib64</userinput></screen>
+
     <para>Install the package:</para>
 
 <screen><userinput remap="install">make install</userinput></screen>
 
-    <para>Next, prepare the linker for the <quote>Adjusting</quote> phase
+    <para>Finally, prepare the linker for the <quote>Adjusting</quote> phase
     later on:</para>
 
 <screen><userinput remap="adjust">make -C ld clean

chapter05/gcc-pass1.xml

@@ -62,7 +62,7 @@ cd ../gcc-build</userinput></screen>
 
 <screen><userinput remap="configure">CC="gcc -B/usr/bin/" ../gcc-&gcc-version;/configure --prefix=/tools \
     --with-local-prefix=/tools --disable-nls --disable-shared --disable-libssp \
-    --enable-languages=c</userinput></screen>
+    --disable-multilib --enable-languages=c</userinput></screen>
 
     <variablelist>
       <title>The meaning of the configure options:</title>
@@ -114,6 +114,13 @@ cd ../gcc-build</userinput></screen>
         </listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><parameter>--disable-multilib</parameter></term>
+        <listitem>
+          <para>We currently only want to build support for 64-bit libraries.</para>
+        </listitem>
+      </varlistentry>
+
     </variablelist>
 
     <para>The following command will compile GCC not once, but several times. It

chapter05/gcc-pass2.xml

@@ -99,7 +99,8 @@ sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \
     GCC. That is, all of the binaries created during the build will link
     against the new Glibc. Issue:</para>
 
-<screen><userinput remap="pre">for file in $(find gcc/config -name linux64.h -o -name linux.h)
+<screen><userinput remap="pre">for file in \
+ $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
 do
   cp -uv $file{,.orig}
   sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&amp;@g' \
@@ -112,7 +113,8 @@ done</userinput></screen>
 
     <para>In case the above seems hard to follow, let's break it down a bit.
     First we find all the files under the gcc/config directory that are named
-    either <filename>linux.h</filename> or <filename>linux64.h</filename>.
+    either <filename>linux.h</filename>, <filename>linux64.h</filename> or
+    <filename>sysv4.h</filename>.
     For each file found, we copy it to a file of the same name but with an added
     suffix of <quote>.orig</quote>. Then the first sed expression prepends
     <quote>/tools</quote> to every instance of <quote>/lib/ld</quote>,
@@ -124,6 +126,14 @@ done</userinput></screen>
     changes to the original files in case the command is inadvertently run twice.
     </para>
 
+    <para>Unsetting the multlib spec for GCC ensures that it
+    won't attempt to link against libraries on the host:</para>
+
+<screen><userinput remap="pre">for file in $(find gcc/config -name t-linux64) ; do \
+   cp -v $file{,.orig}
+   sed '/MULTILIB_OSDIRNAMES/d' $file.orig &gt; $file
+done</userinput></screen>
+
     <para>As in the first build of GCC it requires the GMP and MPFR packages.
     Unpack the tarballs and move them into the required directory names:</para>
 
@@ -146,7 +156,8 @@ cd ../gcc-build</userinput></screen>
     --with-local-prefix=/tools --enable-clocale=gnu \
     --enable-shared --enable-threads=posix \
     --enable-__cxa_atexit --enable-languages=c,c++ \
-    --disable-libstdcxx-pch --disable-bootstrap</userinput></screen>
+    --disable-libstdcxx-pch --disable-multilib \
+    --disable-bootstrap</userinput></screen>
 
     <variablelist>
       <title>The meaning of the new configure options:</title>

chapter05/glibc.xml

@@ -64,7 +64,9 @@ cd ../glibc-build</userinput></screen>
     -mtune=native flag is also necessary to reset a reasonable value for -mtune
     that is changed when setting -march.</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>Next, prepare Glibc for compilation:</para>
 

chapter05/toolchaintechnotes.xml

@@ -27,24 +27,21 @@
 
   <important>
     <para>Before continuing, be aware of the name of the working platform,
-    often referred to as the target triplet. Many times, the target
-    triplet will probably be <emphasis>i686-pc-linux-gnu</emphasis>. A
-    simple way to determine the name of the target triplet is to run the
-    <command>config.guess</command> script that comes with the source for
-    many packages. Unpack the Binutils sources and run the script:
-    <userinput>./config.guess</userinput> and note the output.</para>
+    often referred to as the target triplet. A simple way to determine the
+    name of the target triplet is to run the <command>config.guess</command>
+    script that comes with the source for many packages. Unpack the Binutils
+    sources and run the script: <userinput>./config.guess</userinput> and note
+    the output. For example, for a modern 32-bit Intel processor the
+    output will likely be <emphasis>i686-pc-linux-gnu</emphasis>.</para>
 
     <para>Also be aware of the name of the platform's dynamic linker, often
     referred to as the dynamic loader (not to be confused with the standard
     linker <command>ld</command> that is part of Binutils). The dynamic linker
     provided by Glibc finds and loads the shared libraries needed by a program,
     prepares the program to run, and then runs it. The name of the dynamic
-    linker will usually be <filename class="libraryfile">ld-linux.so.2</filename>.
-    On platforms that are less prevalent, the name might be <filename
-    class="libraryfile">ld.so.1</filename>, and newer 64 bit platforms might
-    be named something else entirely. The name of the platform's dynamic linker
-    can be determined by looking in the <filename class="directory">/lib</filename>
-    directory on the host system. A sure-fire way to determine the name is to
+    linker for a 32-bit Intel machine will be
+    <filename class="libraryfile">ld-linux.so.2</filename>.
+    A sure-fire way to determine the name of the dynamic linker is to
     inspect a random binary from the host system by running:
     <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>
     and noting the output. The authoritative reference covering all platforms

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

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

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>
 

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
@@ -196,6 +211,18 @@ cd ../gcc-build</userinput></screen>
 <screen><computeroutput>SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
 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"

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>
 

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

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>