Added -mtune to Glibc CFLAGS

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

5 files changed, 36 insertions, 22 deletions

diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml
index 4fe48c454..1b2ed4583 100644
--- a/chapter01/changelog.xml
+++ b/chapter01/changelog.xml
@@ -37,6 +37,15 @@
 -->
 
      <listitem>
+      <para>2007-10-05</para>
+      <itemizedlist>
+        <listitem>
+          <para>[bdubbs] - Added -mtune to Glibc CFLAGS.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
+     <listitem>
       <para>2007-10-04</para>
       <itemizedlist>
         <listitem>
diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml
index 75cc56063..4f8152c6e 100644
--- a/chapter05/glibc.xml
+++ b/chapter05/glibc.xml
@@ -55,10 +55,13 @@ cd ../glibc-build</userinput></screen>
     the flag is best placed inside the build variable <quote>CFLAGS</quote>.
     Instead of overriding completely what Glibc's internal build system uses
     for CFLAGS, append the new flag to the existing contents of CFLAGS by
-    making use of the special file <filename>configparms</filename>:</para>
+    making use of the special file <filename>configparms</filename>. The
+    -mtune=native flag is also necessary to reset a reasonable value for -mtune
+    that is changed when setting -march.</para>
 
-<screen><userinput remap="configure">uname -m | grep -q i[4-7]86 &amp;&amp;
-echo "CFLAGS += -march=i486" &gt; configparms</userinput></screen>
+<screen><userinput remap="configure">if [ uname -m | grep -q i[4-7]86 ]; do
+  echo "CFLAGS += -march=i486" &gt; configparms
+done</userinput></screen>
 
     <para>Next, prepare Glibc for compilation:</para>
 
diff --git a/chapter06/glibc.xml b/chapter06/glibc.xml
index 071398151..4134ee453 100644
--- a/chapter06/glibc.xml
+++ b/chapter06/glibc.xml
@@ -104,10 +104,11 @@ unset DL</userinput></screen>
 <screen><userinput remap="pre">mkdir -v ../glibc-build
 cd ../glibc-build</userinput></screen>
 
-    <para>Again, add the needed compiler flag to CFLAGS for x86 machines:</para>
+    <para>Again, add the needed compiler flags to CFLAGS for x86 machines:</para>
 
-<screen><userinput remap="configure">uname -m | grep -q i[4-7]86 &amp;&amp;
-echo "CFLAGS += -march=i486" &gt; configparms</userinput></screen>
+<screen><userinput remap="configure">if [ uname -m | grep -q i[4-7]86 ]; do
+  echo "CFLAGS += -march=i486" &gt; configparms
+done</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/general.ent b/general.ent
index 3c6f61846..b6c0002d8 100644
--- a/general.ent
+++ b/general.ent
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!ENTITY version "SVN-JH-20071004">
-<!ENTITY releasedate "October 4, 2007">
+<!ENTITY version "SVN-JH-20071005">
+<!ENTITY releasedate "October 5, 2007">
 <!ENTITY milestone "7.0">
 <!ENTITY generic-version "development"> <!-- Use "development", "testing", or "x.y[-pre{x}]" -->