Re: Autoconf does not like "-D_FORTIFY_SOURCE=2 -O2"

[Allan McRae]

On 09/05/13 13:36, Eric Blake wrote:
> On 05/08/2013 09:19 PM, Allan McRae wrote:
>> I believe autoconf uses "CPP CPPFLAGS" to detect headers mainly because
>> of "-I" flags needing to be considered.  Would an acceptable solution at
>> the autoconf level be to split the CPPFLAGS into -I flags and others
>> (-D, -U) and just use the -I ones in the header test?
>>
>> If that is fine in principle, I can attempt to implement it.
> 
> But that won't help you instantly fix the hundreds of existing packages
> whose configure script was generated with an earlier version of
> autoconf.  While I am open to making future autoconf have saner behavior
> by default, you MUST consider the fact that your distro's choice of
> CFLAGS vs. CPPFLAGS is the real problem here ("if it hurts, don't do
> it"), rather than waiting for a patched autoconf to trickle down into
> fixed configure scripts on boatloads of packages.

I'm not worried about my distros choice of CPPFLAGS/CFLAGS.  The flags
are being defined where they should be defined and working around it in
the relatively few software packages that this causes issues is a single
sed in the build script.  Hiding the issue only delays it actually being
fixed at the source.


Saying that, it is really only an issue in a few places...   I have
looked into why and it seems to be due to a choice of which
ac_fn_c_check_header_* functions is used.  Looking in binutils (where
all configure files are generated with autoconf 2.64), the configure
files that fail use "ac_fn_c_check_header_preproc" while the ones that
succeed use "ac_fn_c_check_header_mongrel" or
"ac_fn_c_check_header_compile".

How is it determined which of those is used?  From what I can tell
looking at the latest binutils source the working and failing
(libiberty) configure.ac files all use AC_CHECK_HEADERS.

Allan