[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
options.
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
HAVE_LP64
#endif
#ifdef _ILP32
HAVE_ILP32
#endif
...
then eliminates the redundant #line statements and whitespace.
2. Compiles and runs a file such as
#include <stdio.h>
int main () {
#ifdef _LP64
puts("HAVE_LP64");
#endif
#ifdef _ILP32
puts("HAVE_ILP32');
#endif
...
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)
155a156
> #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.
Bruno