[Bug bootstrap/12746] New: configure fails to find out whether a system has ANSI C header files

[Bug bootstrap/12746] New: configure fails to find out whether a system has ANSI C header files

[falemagn at studenti dot unina dot it]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

           Summary: configure fails to find out whether a system has ANSI C
                    header files
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: falemagn at studenti dot unina dot it
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i386-pc-aros
GCC target triplet: i686-pc-linux-gnu

I tested this only with AROS as host system, however it looks like it should
happen with any other host system, given that the host system is different than
the build one.

Basically, configure tries to find out whether the system has ANSI C header
files by compiling a piece of code and then running it. However, when the host
and the build system are different this approach miserably fails. This is an
excerpt from the config.log file:

    configure:1513: checking for ANSI C header files
    configure:1526: i386-aros-gcc -E  conftest.c >/dev/null 2>conftest.out
    configure:1593: i386-aros-gcc -o conftest -g -O2   conftest.c  1>&5
    configure: failed program was:
    #line 1582 "configure"
    #include "confdefs.h"
    #include <ctype.h>
    #define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
    #define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
    #define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
    int main () { int i; for (i = 0; i < 256; i++)
    if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2);
    exit (0); }

Of course it would fail, as it's trying to run on the build system an executable
for a foreign platform!

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[dhazeghi at yahoo dot com]

------- Additional Comments From dhazeghi at yahoo dot com  2003-11-08 19:46 -------
I don't quite understand the problem here. GCC doesn't try and run conftest, it
only tries to build (compile and like) it. Where build!=host, this should be
perfectly acceptable. If it can't compile a program using ANSI C headers, how
can it compile the whole of gcc? Where is the problem? Thanks.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |build


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[falemagn at studenti dot unina dot it]

------- Additional Comments From falemagn at studenti dot unina dot it  2003-11-12 16:09 -------
(In reply to comment #1)
> I don't quite understand the problem here. GCC doesn't try and run conftest,
> it only tries to build (compile and like) it.

I must disagree here. Looking at the configure file, I see this:

[...]
if { (eval echo configure:1593: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && t
est -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
then
  :
else
  echo "configure: failed program was:" >&5
  cat conftest.$ac_ext >&5
  rm -fr conftest*
  ac_cv_header_stdc=no
fi
[...]

And as you see, it does (./conftest; exit).

However, the above code *shouldn't* be run if the compiler used is a cross
compiler, because of this:

[...]
if test "$cross_compiling" = yes; then
  :
else
  cat > conftest.$ac_ext <<EOF
[...]

It should take the "then" branch in my case, but it does not. In fact, running
the configure script shows that it tries to detect whether ANSI C header files
are present *before* it detects whether the compiler used is a crosscompiler:

[...]
checking for ANSI C header files... no
checking for uintptr_t... yes
checking for pid_t... yes
checking whether the C compiler (i386-aros-gcc -nix -g -O2 ) works... yes
checking whether the C compiler (i386-aros-gcc -nix -g -O2 ) is a
cross-compiler... yes
[...]

So the problem really is that the last check should be done first.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[dhazeghi at yahoo dot com]

------- Additional Comments From dhazeghi at yahoo dot com  2003-11-14 07:45 -------
Okay, I see what you mean. I think you're probably right, though I'm not a configury expert. Let's 
see what Nathan thinks... Given how infrequently Canadian crosses are used building gcc, I 
wouldn't be surprised.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neroden at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-11-14 07:45:28
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2003-11-14 19:42 -------
Analysis sounds correct, but...

Which configure file is this?  The one in the gcc/ subdir?
Is the problem still present in mainline?

Can you track down which autoconf macro is expanding to this link attempt?  That
would be a great help in fixing the problem.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[falemagn at studenti dot unina dot it]

------- 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

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[falemagn at studenti dot unina dot it]

------- Additional Comments From falemagn at studenti dot unina dot it  2003-11-17 11:30 -------
(In reply to comment #5)
> it's the AC_CHECK_TYPE macro which is used, and this macro in turn uses the 
> AC_CHECK_TYPE macro.

Sorry, that was meant to be "this macro in turn uses the AC_HEADER_STDC macro".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2004-04-07 00:59 -------
This looks like it's fixed on mainline.  Please try mainline. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746

[Bug bootstrap/12746] configure fails to find out whether a system has ANSI C header files

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-07 03:40 -------
Closing as fixed as no response in 3 months.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12746