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:
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998>.
> I wonder if 'confdefs.h' would benefit from '#ifndef / #define / #endif'
guards.
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:
<https://savannah.gnu.org/support/?110382>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
