瀏覽代碼

* Upgraded to HJL Binutils-2.17.50.0.18
* Initial update of commands to work with both x86 and x86_64


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

Jeremy Huntwork 18 年之前
父節點
當前提交
da2f9fe32c
共有 8 個文件被更改,包括 80 次插入49 次删除
  1. 16 0
      chapter01/changelog.xml
  2. 2 2
      chapter01/whatsnew.xml
  3. 12 9
      chapter05/adjusting.xml
  4. 11 12
      chapter05/toolchaintechnotes.xml
  5. 22 3
      chapter06/gcc.xml
  6. 12 18
      chapter06/readjusting.xml
  7. 1 1
      general.ent
  8. 4 4
      packages.ent

+ 16 - 0
chapter01/changelog.xml

@@ -39,6 +39,12 @@
     <listitem>
       <para>2007-08-07</para>
       <itemizedlist>
+	<listitem>
+	  <para>[jhuntwork] - Upgraded to HJL Binutils-2.17.50.0.18</para>
+	</listitem>
+	<listitem>
+	  <para>[jhuntwork] - Update commands to work with both x86 and x86_64</para>
+	</listitem>
         <listitem>
           <para>[jhuntwork] - Use '-n' when creating /tools/lib64 symlink.
 	  Will fail if that directory or symlink already exists, instead of
@@ -62,6 +68,16 @@
       </itemizedlist>
     </listitem>
 
+    <listitem>
+      <para>2007-08-04</para>
+      <itemizedlist>
+        <listitem>
+          <para>[dnicholson] - Added the <parameter>--disable-werror</parameter>
+          parameter to Binutils Pass 1.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
     <listitem>
       <para>2007-07-31</para>
       <itemizedlist>

+ 2 - 2
chapter01/whatsnew.xml

@@ -39,11 +39,11 @@
     </listitem>
     <listitem>
       <para>Berkeley DB &db-version;</para>
-    </listitem>
+    </listitem> -->
     <listitem>
       <para>Binutils &binutils-version;</para>
     </listitem>
-    <listitem>
+    <!--<listitem>
       <para>Bison &bison-version;</para>
     </listitem>
     <listitem>

+ 12 - 9
chapter05/adjusting.xml

@@ -36,20 +36,22 @@ ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld</userinput></screen>
 
   <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>/lib64/ld-linux-x86-64.so.2</quote>
-  have been replaced with <quote>/tools/lib64/ld-linux-x86-64.so.2</quote>:</para>
+  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-x86-64.so.2</filename>,
-    replace <quote>ld-linux-x86-64.so.2</quote> with the name of the platform's
+    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>
+    linkend="ch-tools-toolchaintechnotes" role=","/> if necessary. Additionally,
+    note that on 64-bit machines the linker may actually be expected in the
+    <filename class="directory">/lib64</filename> directory.</para>
   </important>
 
 <!-- Ampersands are needed to allow copy and paste -->
-<screen><userinput>gcc -dumpspecs | sed 's@/lib64/ld-linux-x86-64.so.2@/tools&amp;@g' \
-  > `dirname $(gcc -print-libgcc-file-name)`/specs</userinput></screen>
+<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
   (<command>fixincludes</command>) that scans the system for header files
@@ -84,9 +86,10 @@ readelf -l a.out | grep ': /tools'</userinput></screen>
     and the output of the last command will be of the form:</para>
 
 <screen><computeroutput>[Requesting program interpreter:
-    /tools/lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
+    /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,

+ 11 - 12
chapter05/toolchaintechnotes.xml

@@ -27,22 +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>x86_64-unknown-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-x86-64.so.2</filename>.
-    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
@@ -96,8 +95,8 @@
   seen during its run of <command>configure</command> is:</para>
 
 <screen><computeroutput>checking what assembler to use...
-        /tools/x86_64-unknown-linux-gnu/bin/as
-checking what linker to use... /tools/x86_64-unknown-linux-gnu/bin/ld</computeroutput></screen>
+        /tools/i686-pc-linux-gnu/bin/as
+checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen>
 
   <para>This is important for the reasons mentioned above. It also demonstrates
   that GCC's configure script does not search the PATH directories to find which

+ 22 - 3
chapter06/gcc.xml

@@ -154,9 +154,17 @@ cd ../gcc-build</userinput></screen>
     href="readjusting.xml"
     xpointer="xpointer(//*[@os='f'])"/>
 
-<screen><computeroutput>/usr/lib/gcc/x86_64-unknown-linux-gnu/&gcc-version;/../../../../lib64/crt1.o succeeded
-/usr/lib/gcc/x86_64-unknown-linux-gnu/&gcc-version;/../../../../lib64/crti.o succeeded
-/usr/lib/gcc/x86_64-unknown-linux-gnu/&gcc-version;/../../../../lib64/crtn.o succeeded</computeroutput></screen>
+<screen><computeroutput>/usr/lib/gcc/x86_64-unknown-linux-gnu/&gcc-version;/../../../crt1.o succeeded
+/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"
@@ -173,6 +181,9 @@ cd ../gcc-build</userinput></screen>
  /usr/lib/gcc/x86_64-unknown-linux-gnu/&gcc-version;/include
  /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>
+
     <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
     href="readjusting.xml"
     xpointer="xpointer(//*[@os='i'])"/>
@@ -185,6 +196,14 @@ cd ../gcc-build</userinput></screen>
     href="readjusting.xml"
     xpointer="xpointer(//*[@os='k'])"/>
 
+<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")

+ 12 - 18
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-x86-64.so.2</filename>,
-    substitute <quote>ld-linux-x86-64.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/lib64/ld-linux-x86-64.so.2@/lib64/ld-linux-x86-64.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>
@@ -66,7 +57,7 @@ readelf -l a.out | grep ': /lib'</userinput></screen>
   and the output of the last command will be (allowing for
   platform-specific differences in dynamic linker name):</para>
 
-<screen os="c"><computeroutput>[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
+<screen os="c"><computeroutput>[Requesting program interpreter: /lib/ld-linux.so.2]</computeroutput></screen>
 
   <para>Note that <filename class="directory">/lib</filename> is now
   the prefix of our dynamic linker.</para>
@@ -97,20 +88,22 @@ 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/x86_64-unknown-linux-gnu/lib")
+<screen><computeroutput>SEARCH_DIR("/tools/i686-pc-linux-gnu/lib")
 SEARCH_DIR("/usr/lib")
 SEARCH_DIR("/lib");</computeroutput></screen>
 
   <para os="l">Next make sure that we're using the correct libc:</para>
 
-<screen os="m"><userinput>grep "/lib64/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 /lib64/libc.so.6 succeeded</computeroutput></screen>
+<screen os="o"><computeroutput>attempt to open /lib/libc.so.6 succeeded</computeroutput></screen>
 
   <para os="p">Lastly, make sure GCC is using the correct dynamic linker:</para>
 
@@ -118,9 +111,10 @@ 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-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2</computeroutput></screen>
+<screen os="s"><computeroutput>found ld-linux.so.2 at /lib/ld-linux.so.2</computeroutput></screen>
 
   <para os="t">If the output does not appear as shown above or is not received
   at all, then something is seriously wrong. Investigate and retrace the

+ 1 - 1
general.ent

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!ENTITY version "SVN-x86_64-20070807">
+<!ENTITY version "SVN-JH-20070807">
 <!ENTITY releasedate "August 7, 2007">
 <!ENTITY milestone "7.0">
 <!ENTITY generic-version "development"> <!-- Use "development", "testing", or "x.y[-pre{x}]" -->

+ 4 - 4
packages.ent

@@ -38,10 +38,10 @@
 <!ENTITY bash-doc-md5 "0e904cb46ca873fcfa65df19b024bec9">
 <!ENTITY bash-doc-home " ">
 
-<!ENTITY binutils-version "2.17">
-<!ENTITY binutils-size "13,472 KB">
-<!ENTITY binutils-url "&gnu;binutils/binutils-&binutils-version;.tar.bz2">
-<!ENTITY binutils-md5 "e26e2e06b6e4bf3acf1dc8688a94c0d1">
+<!ENTITY binutils-version "2.17.50.0.18">
+<!ENTITY binutils-size "13,599 KB">
+<!ENTITY binutils-url "http://www.kernel.org/pub/linux/devel/binutils/binutils-&binutils-version;.tar.bz2">
+<!ENTITY binutils-md5 "98e21a7c0d82b318fe29f2e04d273344">
 <!ENTITY binutils-home "http://sources.redhat.com/binutils/">
 <!ENTITY binutils-ch5p1-du "213 MB">
 <!ENTITY binutils-ch5p1-sbu "1 SBU">