The symptom is early glibc build failure for 32-bit ABI on 64-bit multilib system: python3 -B ../scripts/gen-as-const.py --cc="x86_64-pc-linux-gnu-gcc -m32 -O2 -std=gnu11 -fgnu89-inline -O2 -Wall -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math -fstack-protector-strong -fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno -ftls-model=initial-exec -U_FORTIFY_SOURCE -I../include -I/tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/csu -I/tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl -I../sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/i386/i686/nptl -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/x86/nptl -I../sysdeps/i386/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../sysdeps/i386/i686 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../sysdeps/i386 -I../sysdeps/x86/include -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/32/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS \ -MD -MP -MF /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/cpu-features-offsets.h.dT \ -MT '/tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/cpu-features-offsets.h.d /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/cpu-features-offsets.h'" \ ../sysdeps/x86/cpu-features-offsets.sym > /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/cpu-features-offsets.hT touch /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/gnu/lib-names-32.stmp if test -r /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/abi-tag.h.new; then mv -f /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/abi-tag.h.new /tmp/portage-tmpdir/portage/sys-libs/glibc-9999/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/abi-tag.h; \ else echo >&2 'This configuration not matched in ../abi-tags'; exit 1; fi <stdin>:1:10: fatal error: stddef.h: No such file or directory gcc-11.2.0 works while gcc-12.0.0 does not. I debugged it down to the following different in fresh gcc: $ for d in include include-fixed; do h gcc-12.0.0 -m32 -print-file-name=$d; done /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/32/include /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include-fixed $ for d in include include-fixed; do h gcc-11.2.0 -m32 -print-file-name=$d; done /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed $ ls /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/32/include ISO_Fortran_binding.h glibc detects isystem at https://sourceware.org/git/?p=glibc.git;a=blob;f=configure.ac;h=34ecbba540546337b5ec321fc6168c9544b39214;hb=HEAD#l1086 1086 # if using special system headers, find out the compiler's sekrit 1087 # header directory and add that to the list. NOTE: Only does the right 1088 # thing on a system that doesn't need fixincludes. (Not presently a problem.) 1089 if test -n "$sysheaders"; then 1090 SYSINCLUDES=-nostdinc 1091 for d in include include-fixed; do 1092 i=`$CC -print-file-name="$d"` && test "x$i" != x && test "x$i" != "x$d" && 1093 SYSINCLUDES="$SYSINCLUDES -isystem $i" 1094 done ... I think the header difference is real and we should expect to stay for a while: --- /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/32/include/ISO_Fortran_binding.h 2021-08-03 17:21:45.915152915 +0100 +++ /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/ISO_Fortran_binding.h 2021-08-03 17:21:47.106164843 +0100 @@ -197,3 +197,3 @@ -#define CFI_type_int128_t -2 -#define CFI_type_int_least128_t -2 -#define CFI_type_int_fast128_t -2 +#define CFI_type_int128_t (CFI_type_Integer + (16 << CFI_type_kind_shift)) +#define CFI_type_int_least128_t (CFI_type_Integer + (16 << CFI_type_kind_shift)) +#define CFI_type_int_fast128_t (CFI_type_Integer + (16 << CFI_type_kind_shift))
Proposed simple extension of `include` discovery as https://sourceware.org/pipermail/libc-alpha/2021-August/129808.html
Apparently the underlying change was backported to the gcc-11 branch (where we now see it in Gentoo in a recent snapshot).
(In reply to Andreas K. Huettel from comment #2) > Apparently the underlying change was backported to the gcc-11 branch > (where we now see it in Gentoo in a recent snapshot). We seem to be hitting something else (which looks very similar), sorry.
I believe gcc rolled arch-specific headers back in https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73 Thus not an immediate failure. Given that there was no feedback at all on the ML or IRC and I don't use multilib gccs I'm closing it as OBSOLETE.