bug-autoconf
[Top][All Lists]
Advanced

[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:
<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/




reply via email to

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