gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include For x86_64's 32-bit architecture support, this creates a subdirectory named 'include' inside $(libsubdir)/32 which didn't use to exist in gcc 8.
glibc's configure script, when configured with --with-headers=, uses the following logic to guess at gcc's internal include directories. This failes on gcc 9 because with -m32 now we will get $(gfor_cdir) as the return for -print-file-name=include, instead of the real directory that contains all the include files, $(libsubdir)/include. The result is that SYSINCLUDES is incorrectly defined and the rest of the build fails due to missing standard include files, eg stddef.h etc. # if using special system headers, find out the compiler's sekrit # header directory and add that to the list. NOTE: Only does the right # thing on a system that doesn't need fixincludes. (Not presently a problem.) if test -n "$sysheaders"; then SYSINCLUDES=-nostdinc for d in include include-fixed; do i=`$CC -print-file-name="$d"` && test "x$i" != x && test "x$i" != "x$d" && SYSINCLUDES="$SYSINCLUDES -isystem $i" done SYSINCLUDES="$SYSINCLUDES \ -isystem `echo $sysheaders | sed 's/:/ -isystem /g'`" if test -n "$CXX"; then CXX_SYSINCLUDES= for cxxheaders in `$CXX -v -S -x c++ /dev/null -o /dev/null 2>&1 \ | sed -n -e '1,/#include/d' -e 's/^ \(\/.*\/[cg]++\)/\1/p'`; do test "x$cxxheaders" != x && CXX_SYSINCLUDES="$CXX_SYSINCLUDES -isystem $cxxheaders" done fi fi AC_SUBST(SYSINCLUDES) AC_SUBST(CXX_SYSINCLUDES) I'm not sure if this is a gcc bug or a glibc bug? Should libgfortran install in the MULTISUBDIR? That's the only include file that goes in there, and it is installing the same include file in all of them, so this seems unnecessary. glibc's configure fragment above also looks extremely fragile though, the CXX_SYSINCLUDES version looks a little more robust, should something similar be done for SYSINCLUDES?