Re: [Vincent Lefevre] Bug#325866: autoconf: AC_COMPILE_IFELSE generates a test that doesn't work on IRIX64

[Ralf Wildenhues]

Hi Ben, Vincent,

* Ben Pfaff wrote on Wed, Aug 31, 2005 at 04:57:36PM CEST:
> 
> AC_COMPILE_IFELSE generates a test that only checks the exit status
> of the compiler command. But this is not sufficient:
*snip*
> demon ~ % cc -DFOO tst.c && echo OK
> cc-1035 cc: WARNING File = tst.c, Line = 2
>   #error directive:  "FOO is defined"
> 
>   # error "FOO is defined"
>     ^
> 
> OK
> demon ~ %
> 
> An a.out program is generated. I'm not sure whether this is conforming
> to the C standard, which says:
> 
>      [#4]  The  implementation shall not successfully translate a
>      preprocessing   translation   unit   containing   a   #error
>      preprocessing directive unless it is part of a group skipped
>      by conditional inclusion.

FWIW, I don't think this is conforming (but I've been wrong on C
standard issues before, so don't count on that).  OTOH, if all software
would conform to standards, Autoconf would be a lot less necessary,
wouldn't it?  :)

> i.e. could the implementation decide that the translation is not
> successful because of the above warning? Anyway, one of the goals
> of the configure script is to detect when things are wrong on the
> current platform. So, I think that autoconf should cope with this
> problem.

Somewhat similar issues have come up a couple of times recently:
http://lists.gnu.org/archive/html/autoconf/2005-07/msg00083.html
http://lists.gnu.org/archive/html/autoconf/2005-07/msg00009.html

One possible solution would be an adaptation of Libtool's boilerplate
code[1] that looks for differing compiler output, to not only test
different compiler switches, but also allow differing input source.

I haven't gotten around to implementing an Autoconf version of it yet;
the semantics for general use are a bit tricky, IMHO.  I would not
mind if someone else did it, either[2].

Even when that is done, I would very much hesitate to use it within
AC_COMPILE_IFELSE: many compilers routinely output information that
varies greatly with the given code, even when the differences are not
in warnings.  For example, compilers that output every function name,
or whether a loop was unrolled.  Given this kind of output, it's
virtually impossible to predict differences in warnings.

Maybe for a subclass of these issues it would suffice to filter out
lines with some keywords in them, like "warning", "error", with
differing case.  Still sounds like a very hacky and ad-hoc solution,
and would not be without false positives either, see e.g. [3].

Cheers,
Ralf

[1] mentioned in this thread:
http://lists.gnu.org/archive/html/autoconf/2005-06/msg00001.html
http://lists.gnu.org/archive/html/autoconf/2005-05/msg00108.html
(see libtool-1.5.20/libtool.m4:AC_LIBTOOL_COMPILER_OPTION and
_LT_COMPILER_BOILERPLATE for the code used within Libtool)

[2] Note, that there is also a bug in the current implementation: it
needs to weed out at least some "set -x" related shell debug output,
else running a configure script like this will cause Heisen-antibugs.

[3] http://lists.gnu.org/archive/html/libtool/2005-06/msg00110.html