Update to gcc-13.2.0.

general/prog/gcc.xml

@@ -7,10 +7,10 @@
   <!ENTITY gcc-download-http  "&gnu-http;/gcc/gcc-&gcc-version;/gcc-&gcc-version;.tar.xz">
   <!ENTITY gcc-download-ftp   "&gnu-ftp;/gcc/gcc-&gcc-version;/gcc-&gcc-version;.tar.xz">
   <!-- Update this also on the grub-uefi page -->
-  <!ENTITY gcc-md5sum         "43e4de77f2218c83ca675257ea1af9ef">
+  <!ENTITY gcc-md5sum         "e0e48554cc6e4f261d55ddee9ab69075">
-  <!ENTITY gcc-size           "83 MB">
+  <!ENTITY gcc-size           "84 MB">
-  <!ENTITY gcc-buildsize      "9.6 GB (2.4 GB installed with all listed languages; add 1.4 GB for tests)">
+  <!ENTITY gcc-buildsize      "13 GB (2.9 GB installed with all listed languages; add 1.5 GB for tests)">
-  <!ENTITY gcc-time           "32 SBU (add 55 SBU for tests; both with parallelism=4)">
+  <!ENTITY gcc-time           "13 SBU (add 29 SBU for tests; both with parallelism=8)">
 ]>
 
 <sect1 id="gcc" xreflabel="GCC-&gcc-version;">
@@ -63,24 +63,6 @@
         headers from the ones used when <application>Glibc</application> was
         compiled during LFS.
       </para>
-<!--
-      <para>
-        Some system headers need to be fixed to be used with GCC. This is done
-        during the installation of GCC, and the <quote>fixed</quote> headers
-        are installed in <filename class="directory">
-        /usr/lib/gcc/&lt;machine triplet&gt;/&lt;GCC version&gt;/include-fixed
-        </filename>. This is harmless if GCC is built during the LFS stage. But
-        if you reinstall GCC in BLFS, some of the BLFS packages may be
-        <quote>fixed</quote>. If one of those packages is reinstalled
-        afterwards, the <quote>fixed</quote> headers are not updated, which may
-        lead to version mismatches. In case that happens, the
-        <quote>fixed</quote> headers must be updated by running (as
-        <systemitem class="username">root</systemitem>):
-        <command>
-         /usr/libexec/gcc/x86_64-pc-linux-gnu/&gcc-version;/install-tools/mkheaders
-        </command>. The machine triplet may be different on a 32-bit system.
-      </para>
--->
     </caution>
 
     <bridgehead renderas="sect3">Package Information</bridgehead>
@@ -172,20 +154,7 @@
       bootstrap anyway, add <parameter>--disable-bootstrap</parameter> to the
       <command>./configure</command> options below.
     </para>
-<!--
-    <para>
-      Some packages checks on the phrase <literal>gccgo</literal> in the output
-      of <command>go version</command> to see which kind of Go compiler is
-      installed (gcc-go or golang). The absence of <literal>gccgo</literal> in
-      that string makes them to assume the compiler is the golang which is wrong.
-      If Go isn't in the list of desired languages, this patch can be skipped
-      while it does not harm if applied anyway. Fix the Go part of gcc to show
-      a valid version string when calling <command>go version</command> by
-      applying a patch:
-    </para>
 
-<screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-fix_go_version-1.patch</userinput></screen>
--->
     <para>
       Install <application>GCC</application> by running the following commands:
     </para>
@@ -214,11 +183,11 @@ make</userinput></screen>
       <application>valgrind</application> and <application>gdb</application>,
       the <application>gcc</application> part of the test suite will run more
       tests than in LFS. Some of those will report FAIL and others XPASS
-      (pass when expected to FAIL). As of gcc-13.1.0, about 60 FAIL occur
+      (pass when expected to FAIL). As of gcc-13.2.0, about 65 FAIL occur
       in the <quote>guality</quote> suite, as well as miscellaneous failures
       throughout the rest of the test suite.
       If all the compilers above are built, there will be a little over 80 
-      unexpected failures out of over 478,000 tests. To run the tests, issue:
+      unexpected failures out of over 546,000 tests. To run the tests, issue:
     </para>
 
 <screen><userinput>ulimit -s 32768 &amp;&amp;
@@ -246,20 +215,6 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib &amp;&amp;
 chown -v -R root:root \
     /usr/lib/gcc/*linux-gnu/&gcc-version;/include{,-fixed}</userinput></screen>
 
-    <para>
-      Some packages expect to find the C preprocessor in
-      <filename class="directory">/lib</filename> or may refer to the C compiler
-      under the name <command>cc</command>. The following symbolic links are not
-      needed if you have followed the LFS instructions, since they
-      have been already created. If you do not have them on your system, issue
-      as the <systemitem class="username">root</systemitem> user:
-    </para>
-
-<screen role="root"><userinput>ln -v -sf ../usr/bin/cpp /lib          &amp;&amp;
-ln -v -sf gcc /usr/bin/cc              &amp;&amp;
-install -v -dm755 /usr/lib/bfd-plugins &amp;&amp;
-ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/&gcc-version;/liblto_plugin.so /usr/lib/bfd-plugins/</userinput></screen>
-
   </sect2>
 
   <sect2 role="commands">

introduction/welcome/changelog.xml

@@ -38,6 +38,16 @@
       </itemizedlist>
     </listitem>
     -->
+   <listitem>
+     <para>July 30th, 2023</para>
+     <itemizedlist>
+       <listitem>
+         <para>[bdubbs] - Update to gcc-13.2.0. Fixes
+         <ulink url="&blfs-ticket-root;18341">#18341</ulink>.</para>
+       </listitem>
+     </itemizedlist>
+   </listitem>
+
    <listitem>
      <para>July 28th, 2023</para>
      <itemizedlist>

packages.ent

@@ -313,7 +313,7 @@ to avoid building libxml2 twice, which is slow with all deps -->
 <!ENTITY cmake-minor-version          "1">
 <!ENTITY cmake-version                "&cmake-major-version;.&cmake-minor-version;">
 <!ENTITY doxygen-version              "1.9.7">
-<!ENTITY gcc-version                  "13.1.0">
+<!ENTITY gcc-version                  "13.2.0">
 <!ENTITY gc-version                   "8.2.4">
 <!ENTITY gdb-version                  "13.2">
 <!ENTITY git-version                  "2.41.0">