[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Don’t use AC_EGREP_CPP if affected by CFLAGS

From: Bruno Haible
Subject: Re: [PATCH] Don’t use AC_EGREP_CPP if affected by CFLAGS
Date: Tue, 07 Nov 2017 01:57:57 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-97-generic; KDE/5.18.0; x86_64; ; )

Paul Eggert wrote:
> In contrast, it's relatively simple to say "Don't use AC_EGREP_CPP 
> unless you know the result isn't likely to depend on compiler options."

No one can reasonably assert that a certain test is not dependent on compiler
  1) because there are unexpected cases, such as #include <sys/procfs.h>
     on Solaris, which does totally different things when _FILE_OFFSET_BITS=64
     is defined.
  2) because few developers try different compilation options. Most stick
     with their "usual" environment variables.

Therefore, making such a requirement on the use of AC_EGREP_CPP is similar
to forbidding the use of AC_EGREP_CPP entirely. Which doesn't help in the
attempt of making configure scripts execute fast.

> > When the error rate is so high, we should
> >    1) improve the documentation (this is mainly install.texi from Autoconf),
> >    2) add a consistency check in AC_PROG_CC or AC_PROG_CPP.
> >
> (2) would be better than what we have now, yes. But how could such a 
> check be implemented robustly? Wouldn't it require a comprehensive 
> knowledge of which compiler options affect which predefined macros on 
> which platforms?

Yes. But this is solvable:
  * The list of such macros is finite.
  * I imagine a test that
    1. runs through $CPP a file such as

        #ifdef _LP64
        #ifdef _ILP32

      then eliminates the redundant #line statements and whitespace.
    2. Compiles and runs a file such as

        #include <stdio.h>
        int main () {
        #ifdef _LP64
        #ifdef _ILP32
        return 0;
    3. Compares the two results.
    This way, the test can catch differences in any number of macros in
    1 $CPP run + 1 $CC run.

> The problem is not limited to flags like -m32 and -m64. Flags like 
> -fsanitize=address can also affect preprocessor behavior. A complete 
> list of such flags would be daunting to maintain.

I didn't know about the -fsanitize=address effect, but it is easy to determine:

$ diff <(:|gcc -E -dM -|LC_ALL=C sort) <(:|gcc -fsanitize=address -E -dM 
-|LC_ALL=C sort)
> #define __SANITIZE_ADDRESS__ 1

We can even do this automatically for all gcc options that appear in the
"gcc --help" output, like we did for the warning options.

Once we have determined this list, it will cover nearly all cases, with only
occasional updates.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]