Changes in chapter08/gcc.xml [560c147:2b76c89]

File:

• chapter08/gcc.xml (modified) (9 diffs)

chapter08/gcc.xml

@@ -42 +42 @@
     <title>Installation of GCC</title>
 
-    <para>Set the default directory name for
-    64-bit libraries to <quote>lib</quote>:</para>
-
-<screen><userinput remap="pre">sed -e 's/lib64/lib/' \
-    -i.orig gcc/config/loongarch/{t-linux,linux.h}</userinput></screen>
+    <para>If building on x86_64, change the default directory name for 64-bit
+    libraries to <quote>lib</quote>:</para>
+
+<screen><userinput remap="pre">case $(uname -m) in
+  x86_64)
+    sed -e '/m64=/s/lib64/lib/' \
+        -i.orig gcc/config/i386/t-linux64
+  ;;
+esac</userinput></screen>
 
     <para>The GCC documentation recommends building GCC in a dedicated build directory:</para>
@@ -136 +140 @@
     </important>
 
-   <para>One set of tests in the GCC test suite is known to exhaust the default
-   stack, so increase the stack size prior to running the tests:</para>
-
-<screen><userinput remap="test">ulimit -s 32768</userinput></screen>
+    <para>GCC may need more stack space compiling some extremely complex
+    code patterns.  As a precaution for the host distros with a tight stack
+    limit, explicitly set the stack size hard limit to infinite.
+    On most host distros (and the final LFS system) the hard limit is
+    infinite by default, but there is no harm done by setting it explicitly.
+    It's not necessary to change the stack size soft limit because GCC will
+    automatically set it to an appropriate value, as long as the value does
+    not exceed the hard limit:</para>
+
+<screen><userinput remap="test">ulimit -s -H unlimited</userinput></screen>
 
     <para>Now remove/fix several known test failures:</para>
 
-<screen><userinput remap="test">sed -e '/cpython/d'               -i ../gcc/testsuite/gcc.dg/plugin/plugin.exp</userinput></screen>
+<screen><userinput remap="test">sed -e '/cpython/d'               -i ../gcc/testsuite/gcc.dg/plugin/plugin.exp
+sed -e 's/no-pic /&amp;-no-pie /'     -i ../gcc/testsuite/gcc.target/i386/pr113689-1.c
+sed -e 's/300000/(1|300000)/'     -i ../libgomp/testsuite/libgomp.c-c++-common/pr109062.c
+sed -e 's/{ target nonpic } //' \
+    -e '/GOTPCREL/d'              -i ../gcc/testsuite/gcc.target/i386/fentryname3.c</userinput></screen>
 
     <para>Test the results as a non-privileged user, but do not stop at errors:</para>
@@ -180 +194 @@
     if the hardware does not support AVX.</para>
 -->
-
-    <!-- gen-vect-*: Likely https://gcc.gnu.org/PR113418
-         pr108357.c: https://gcc.gnu.org/PR108357#c5
-         update-threading.c: https://gcc.gnu.org/PR110628
-         vect-117.c: https://gcc.gnu.org/PR113685
-         pr64076: Binutils bug (ld crashes), needs a triage -->
-    <para>The tests named
-    <filename>gen-vect-11b.c</filename>,
-    <filename>gen-vect-11c.c</filename>,
-    <filename>gen-vect-26.c</filename>,
-    <filename>gen-vect-28.c</filename>,
-    <filename>pr64076</filename>,
-    <filename>pr108357.c</filename>,
-    <filename>update-threading.c</filename>,
-    and <filename>vect-117.c</filename> are known to fail.</para>
-
     <para>A few unexpected failures cannot always be avoided. In some cases
     test failures depend on the specific hardware of the system.<!--The GCC developers
@@ -245 +243 @@
   platform-specific differences in the dynamic linker name):</para>
 
-<screen><computeroutput>[Requesting program interpreter: /lib64/ld-linux-loongarch-lp64d.so.1]</computeroutput></screen>
+<screen><computeroutput>[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]</computeroutput></screen>
 
   <para>Now make sure that we're set up to use the correct start files:</para>
@@ -253 +251 @@
   <para>The output of the last command should be:</para>
 
-<screen><computeroutput>/usr/lib/gcc/loongarch64-unknown-linux-gnu/&gcc-version;/../../../../lib/Scrt1.o succeeded
-/usr/lib/gcc/loongarch64-unknown-linux-gnu/&gcc-version;/../../../../lib/crti.o succeeded
-/usr/lib/gcc/loongarch64-unknown-linux-gnu/&gcc-version;/../../../../lib/crtn.o succeeded</computeroutput></screen>
+<screen><computeroutput>/usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/Scrt1.o succeeded
+/usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crti.o succeeded
+/usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crtn.o succeeded</computeroutput></screen>
 
   <para>Depending on your machine architecture, the above may differ slightly.
@@ -272 +270 @@
 
 <screen><computeroutput>#include &lt;...&gt; search starts here:
- /usr/lib/gcc/loongarch64-unknown-linux-gnu/&gcc-version;/include
+ /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include
  /usr/local/include
- /usr/lib/gcc/loongarch64-unknown-linux-gnu/&gcc-version;/include-fixed
+ /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include-fixed
  /usr/include</computeroutput></screen>
 
@@ -287 +285 @@
   be ignored, but otherwise the output of the last command should be:</para>
 
-<screen><computeroutput>SEARCH_DIR("/usr/loongarch64-unknown-linux-gnu/lib64")
+<screen><computeroutput>SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
 SEARCH_DIR("/usr/local/lib64")
 SEARCH_DIR("/lib64")
 SEARCH_DIR("/usr/lib64")
-SEARCH_DIR("/usr/loongarch64-unknown-linux-gnu/lib")
+SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
 SEARCH_DIR("/usr/local/lib")
 SEARCH_DIR("/lib")
 SEARCH_DIR("/usr/lib");</computeroutput></screen>
-<!--
+
    <para>A 32-bit system may use a few other directories. For example, here
    is the output from an i686 machine:</para>
@@ -307 +305 @@
 SEARCH_DIR("/lib")
 SEARCH_DIR("/usr/lib");</computeroutput></screen>
--->
+
   <para>Next make sure that we're using the correct libc:</para>
 
@@ -323 +321 @@
   platform-specific differences in dynamic linker name):</para>
 
-<screen><computeroutput>found ld-linux-loongarch-lp64d.so.1 at /usr/lib/ld-linux-loongarch-lp64d.so.1</computeroutput></screen>
+<screen><computeroutput>found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2</computeroutput></screen>
 
   <para>If the output does not appear as shown above or is not received