[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files
falemagn at studenti dot unina dot it
gcc-bugzilla@gcc.gnu.org
Mon Nov 17 11:26:00 GMT 2003
------- Additional Comments From falemagn at studenti dot unina dot it 2003-11-17 11:26 -------
(In reply to comment #4)
> Analysis sounds correct, but...
>
> Which configure file is this? The one in the gcc/ subdir?
> Is the problem still present in mainline?
I don't know whether the problem is still present in mainline, however the
culprit configure file is the one in the libiberty/ subdir, which then on turn
spoils also the one in the gcc/ subdir which uses the previously cached wrong value.
> Can you track down which autoconf macro is expanding to this link attempt?
The actual macro which expands in this link attempt is AC_HEADER_STDC, however
this macro is not used directly, it's the AC_CHECK_TYPE macro which is used, and
this macro in turn uses the AC_CHECK_TYPE macro.
>From acgeneral.m4:
dnl AC_CHECK_TYPE(TYPE, DEFAULT)
AC_DEFUN(AC_CHECK_TYPE,
[AC_REQUIRE([AC_HEADER_STDC])dnl
AC_MSG_CHECKING(for $1)
[...]
Now, this macro is used for the first time at line 151 in libiberty/configure.in:
AC_CHECK_TYPE(uintptr_t, unsigned long);
And only much later on the macro AC_PROG_CC_WORKS, which decides whether the
compiler works and is a crosscompiler, is used, at line 397.
Usually the latter macro is not used directly, it's usage is rather triggered by
the AC_PROG_CC macro which usually is put at the top of any configure.in file,
however in the libiberty case the AC_PROG_CC macro is replaced by libiberty's
own LIB_AC_PROG_CC macro, which is used at line 102 in libiberty/configure.in.
libiberty/aclocal.m4, at line 90 states this:
"# FIXME: We temporarily define our own version of AC_PROG_CC. This is
# copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS. We
# are probably using a cross compiler, which will not be able to fully
# link an executable. This should really be fixed in autoconf
# itself.".
> That would be a great help in fixing the problem.
Hope that helps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746
More information about the Gcc-bugs
mailing list