[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vincent Lefevre] Bug#325866: autoconf: AC_COMPILE_IFELSE generates
From: |
Ralf Wildenhues |
Subject: |
Re: [Vincent Lefevre] Bug#325866: autoconf: AC_COMPILE_IFELSE generates a test that doesn't work on IRIX64 |
Date: |
Thu, 1 Sep 2005 08:46:42 +0200 |
User-agent: |
Mutt/1.4.1i |
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
- Re: [Vincent Lefevre] Bug#325866: autoconf: AC_COMPILE_IFELSE generates a test that doesn't work on IRIX64,
Ralf Wildenhues <=