libgloss: build with -nostdinc
We don't want libgloss building against C library headers that happened to be installed with the toolchain, so add -nostdinc to the build. We still need access to the compiler internal headers, so probe those and include them via -isystem. This uses a similar probing style as glibc, which has used it for over a decade, so it should be safe & stable. This should prevent any latent bugs due to testing with a toolchain that is fully configured & installed already.
This commit is contained in:
parent
5ca1f8c7ff
commit
e0c0ad8268
|
@ -5104,6 +5104,26 @@ esac
|
|||
|
||||
|
||||
|
||||
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for compiler search settings" >&5
|
||||
$as_echo_n "checking for compiler search settings... " >&6; }
|
||||
if ${libc_cv_compiler_isystem+:} false; then :
|
||||
$as_echo_n "(cached) " >&6
|
||||
else
|
||||
for subdir in include include-fixed; do
|
||||
if dir=`$CC -print-file-name=$subdir`; then :
|
||||
if test -n "$dir"; then :
|
||||
libc_cv_compiler_isystem="$libc_cv_compiler_isystem -isystem $dir"
|
||||
|
||||
fi
|
||||
|
||||
fi
|
||||
done
|
||||
|
||||
fi
|
||||
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_compiler_isystem" >&5
|
||||
$as_echo "$libc_cv_compiler_isystem" >&6; }
|
||||
CC="$CC -nostdinc $libc_cv_compiler_isystem"
|
||||
|
||||
host_makefile_frag_path=$host_makefile_frag
|
||||
|
||||
|
||||
|
|
|
@ -336,6 +336,17 @@ m4_include([mcore/acinclude.m4])
|
|||
m4_include([mn10300/acinclude.m4])
|
||||
m4_include([moxie/acinclude.m4])
|
||||
|
||||
AC_CACHE_CHECK([for compiler search settings], libc_cv_compiler_isystem, [dnl
|
||||
for subdir in include include-fixed; do
|
||||
AS_IF([dir=`$CC -print-file-name=$subdir`], [dnl
|
||||
AS_IF([test -n "$dir"], [dnl
|
||||
libc_cv_compiler_isystem="$libc_cv_compiler_isystem -isystem $dir"
|
||||
])
|
||||
])
|
||||
done
|
||||
])
|
||||
CC="$CC -nostdinc $libc_cv_compiler_isystem"
|
||||
|
||||
dnl We have to assign the same value to other variables because autoconf
|
||||
dnl doesn't provide a mechanism to substitute a replacement keyword with
|
||||
dnl arbitrary data or pathnames.
|
||||
|
|
Loading…
Reference in New Issue