[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