fedora-32: If gcc 10 is found, install gcc spkg; fix building gcc (9.2.0) spkg with gcc 10

[mkoeppe]

To work around build failures of some SPKGs with gcc 10, in particular on fedora-32 (#29456),
we reject system gcc 10 and build the gcc spkg instead.

That itself requires patches, which we get from https://bugs.gentoo.org/708346, for the following error:

libtool: compile:  /sage/local/var/tmp/sage/build/gcc-9.2.0/gcc-build/./gcc/xgcc -shared-libgcc -B/sage/local/var/tmp/sage/build/gcc-9.2.0/gcc-build/./gcc -nostdinc++ -L/sage/local/var/tmp/sage/build/gcc-9.2.0/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/sage/local/var/tmp/sage/build/gcc-9.2.0/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/sage/local/var/tmp/sage/build/gcc-9.2.0/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/sage/local/x86_64-pc-linux-gnu/bin/ -B/sage/local/x86_64-pc-linux-gnu/lib/ -isystem /sage/local/x86_64-pc-linux-gnu/include -isystem /sage/local/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I. -I../../../../src/libsanitizer/sanitizer_common -I.. -I ../../../../src/libsanitizer/include -isystem ../../../../src/libsanitizer/include/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-pc-linux-gnu -I../../../../src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../src/libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../src/libsanitizer/../include -include ../../../../src/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -D_GNU_SOURCE -MT sanitizer_posix.lo -MD -MP -MF .deps/sanitizer_posix.Tpo -c ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc  -fPIC -DPIC -o .libs/sanitizer_posix.o
In file included from ../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193:
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:339:72: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
  339 |     typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
      |                                                                        ^

To reproduce:

  tox -e docker-fedora-32-standard-gcc_spkg

See also:

• https://bugzilla.redhat.com/show_bug.cgi?id=1774798

CC: @dimpase @kiwifb @orlitzky @vbraun @enriqueartal

Component: packages: standard

Author: Matthias Koeppe

Branch/Commit: ca0d8a4

Reviewer: Michael Orlitzky

Issue created by migration from https://trac.sagemath.org/ticket/29674

[mkoeppe]

comment:2

Let's add the patches from gentoo

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

Branch: u/mkoeppe/fedora_32__building_gcc__9_2_0__spkg_fails_with_gcc_10

[mkoeppe]

Commit: fb71dc0

[mkoeppe]

comment:6

Tests of -gcc_spkg run at https://github.com/mkoeppe/sage/actions/runs/100892171

---

New commits:

790d1b6	build/pkgs/gcc: Add gentoo patch
fb71dc0	build/pkgs/gcc: Remove gentoo-specific part of gentoo patch

[sagetrac-git]

Changed commit from fb71dc0 to d5033ef

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

5214641	.github/workflows/tox-gcc_spkg.yml: New
d5033ef	build/pkgs/gcc/spkg-configure.m4: Reject gcc (gnu) >= 10

[mkoeppe]

comment:11

The test for IS_REALLY_GCC had bitrotted away and as a result the version check actually didn't run. Fixed.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

76dcef3	build/pkgs/gcc: Add gentoo patch
a13e5e9	.github/workflows/tox-gcc_spkg.yml: New
ca0d8a4	build/pkgs/gcc/spkg-configure.m4: Reject gcc (gnu) >= 10

[sagetrac-git]

Changed commit from d5033ef to ca0d8a4

[mkoeppe]

comment:14

New tests running at https://github.com/mkoeppe/sage/actions

[mkoeppe]

comment:17

Some of the new tests for -gcc_spkg at https://github.com/mkoeppe/sage/runs/661787493?check_suite_focus=true have unrelated failures, for which I have opened #29675. These are not important to fix.

[mkoeppe]

comment:18

fedora-32-standard-gcc_spkg (https://github.com/mkoeppe/sage/runs/661787882), fedora-32-standard-python2-gcc_spkg (https://github.com/mkoeppe/sage/runs/661787887) work correctly with this fix.

fedora-32-minimal-gcc_spkg (https://github.com/mkoeppe/sage/runs/661787878) is clean too but times out.

[mkoeppe]

comment:19

And fedora-32-standard (https://github.com/mkoeppe/sage/runs/661788407) shows the changes to the spkg-configure:

hecking whether SageMath should install SPKG gcc...
checking for C compiler vendor... gnu
checking whether g++ supports C++11 features with -std=gnu++11... yes
checking for gcc option to accept ISO C99... none needed
checking if gcc accepts -dumpversion option... yes
checking gcc version... 10
checking if g++ accepts -dumpversion option... yes
checking g++ version... 10
configure: Installing GCC because g++ -std=gnu++11 is g++ version 10, which is too recent for this version of Sage
configure: no suitable system package found for SPKG gcc

The runs on systems other than fedora-32 are unchanged (https://github.com/mkoeppe/sage/actions/runs/100987613).

Ready for review

[orlitzky]

Reviewer: Michael Orlitzky

[orlitzky]

comment:20

Replying to @mkoeppe:

The test for IS_REALLY_GCC had bitrotted away and as a result the version check actually didn't run. Fixed.

I'm skeptical that this worked in the first place (that's a shell pipe, not a regex):

AS_CASE(["$GXX_VERSION.0"],
                [[[0-3]].*|4.[[0-7]].*], [

I can't really test this but the changes are reasonable. The main risk with something like this is that the patches would break something with older glibc, but the fact that upstream backported these two patches to the 9.3 branch suggests that they wouldn't. The CI checks confirm that, and everyone else will be using their system GCC anyway, so let's try it.

[orlitzky]

comment:21

Replying to @orlitzky:

I'm skeptical that this worked in the first place (that's a shell pipe, not a regex):

AS_CASE(["$GXX_VERSION.0"],
                [[[0-3]].*|4.[[0-7]].*], [

Apparently it does, even without bash's extglob. TIL.

[mkoeppe]

comment:22

Thanks!

[vbraun]

Changed branch from u/mkoeppe/fedora_32__building_gcc__9_2_0__spkg_fails_with_gcc_10 to ca0d8a4