[Top][All Lists]

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

[sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#incl

From: Zack Weinberg
Subject: [sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'
Date: Wed, 25 Nov 2020 15:06:30 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of sr #110382 (project autoconf):

                Priority:              5 - Normal => 1 - Later              
                Severity:              3 - Normal => 1 - Wish               
                  Status:                    None => Confirmed              


Follow-up Comment #2:

Autoconf has _always_ implicitly embedded the contents of confdefs.h at the
top of every test program it compiles.  This behavior is at least 20 years
old, probably even longer -- I think I remember autoconf 2.13 doing it.

Your code breaks with 2.69d because AC_USE_SYSTEM_EXTENSIONS defines more
macros now, and that trips what appears to be a bug in *GCC*. Consider this
test fragment:

#define ordinary_macro 1
#define ordinary_macro 1
#define __STDC_anything 1
#define __STDC_anything 1

Compiling with -Werror, I get a "macro __STDC_anything redefined" error with
GCC 9 and 10, but I do *not* get a "macro ordinary_macro redefined" error. 
With clang, I get no errors at all.  I've reported this as a bug in GCC:

> I wonder if 'confdefs.h' would benefit from '#ifndef / #define / #endif'

This is a good idea but will not be possible for 2.70, because confdefs.h is
built up over the course of the configure process, by appending to it with
shell `>>`.  We would have to come up with a way to insert each new definition
_before_ the #endif.  I think this would be possible with clever use of `sed`
but it would be too risky of a change for how close to the release we are.

I'm going to tag this bug to be revisited after the 2.70 release, when we may
be able to make a change along the lines you suggest, and add something to the
release notes about this problem.

Please be aware that running configure tests with -Werror in effect is not
supported.  We cannot currently guarantee that the code generated for various
tests will remain warning-free as C compilers continue to get pickier.  It's
on the TODO list, but it's going to take major internal changes (for instance,
the code generated by AC_CHECK_FUNC is just plain wrong, but we've been
putting off a fix for _decades_ because of how difficult it will be to fix it
without breaking anything).


Reply to this item at:


  Message sent via Savannah

reply via email to

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