This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
- From: Arvind Sankar <nivedita at alum dot mit dot edu>
- To: gcc at gcc dot gnu dot org, libc-help at sourceware dot org
- Date: Wed, 1 May 2019 14:24:58 -0400
- Subject: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
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?