Re: [sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

[Nick Bowler]

On 2023-12-08 09:25, Zack Weinberg wrote:
> Thinking about this one some more, I see two ways to make confdefs.h
> idempotent:
> 
> 1. A conventional "multiple inclusion guard", wrapping the body of the file in
> #ifndef ... #endif.  This will work on all compilers and regardless of whether
> confdefs.h is included or concatenated with the test program, but requires us
> to change AC_DEFINE and friends to do something like
> 
> 
> #define MACRO 1
> 
> 
> The thing I'm worried about with this one is if there's third party macros out
> there somewhere that bypass AC_DEFINE.  The sed construct up there should be
> portable.

I think your sed construct must have been eaten somewhere along the line.  
Without
being able to see the suggestion, I imagine that using sed to rewrite confdefs.h
every time is going to incur quadratic runtime complexity while simply appending
new definitions to an existing file normally does not.

>From what I understand of this issue, I don't think we should change anything
in Autoconf because there does not seem to be any real advantage to fixing this.

  - Excluding the NEWS item which references this one report, the Autoconf 
documentation does not mention confdefs.h even once.  This issue can
only affect packages relying on undocumented Autoconf internals.  It
does not affect normal usage of AC_LANG_SOURCE and friends.

  - We have exactly one report of problems (apr), and this package has been
updated to use AC_LANG_PROGRAM since this was reported.

  - The consequence of this issue is just a compiler warning from a few
versions of one compiler (admittedly an important one).

The bogus warning should just be fixed in gcc.

> 2. Alternatively, use #pragma once and change AC_LANG_CONFTEST(C) to #include
> confdefs.h rather than prepending its contents to the test program.  This
> would keep macros that bypass AC_DEFINE working, but would break with
> compilers that make #pragma once do something wacky (it should be no worse
> than the status quo with compilers that merely _ignore_ #pragma once). I also
> wonder if there's a concrete reason why AC_LANG_CONFTEST(C) _shouldn't_
> #include confdefs.h.

Using nonstandard pragmas seems even worse to me, and just moves the problem
elsewhere (many compilers will warn by default if they encounter "#pragma once"
by default, including older versions of gcc!).

If you really want to work around this gcc bug then it is probably sufficient
to just install special cases in the internal Autoconf macros that generate
these definitions of the problematic macros, for example (untested):

  #ifndef AC_DEFINED__STDC_WANT_IEC_60559_ATTRIBS_EXT__
  #define AC_DEFINED__STDC_WANT_IEC_60559_ATTRIBS_EXT__
  #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
  #endif

Then this could still be inserted to confdefs.h by appending and does not
rely on any nonstandard pragmas.

Cheers,
  Nick

[sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

[Zack Weinberg]

Update of sr#110382 (group autoconf):

Priority: 1 - Blocked => 3 - Release N+1

___

Follow-up Comment #3:

Thinking about this one some more, I see two ways to make confdefs.h
idempotent:

1. A conventional "multiple inclusion guard", wrapping the body of the file in
#ifndef ... #endif.  This will work on all compilers and regardless of whether
confdefs.h is included or concatenated with the test program, but requires us
to change AC_DEFINE and friends to do something like


#define MACRO 1


The thing I'm worried about with this one is if there's third party macros out
there somewhere that bypass AC_DEFINE.  The sed construct up there should be
portable.

2. Alternatively, use #pragma once and change AC_LANG_CONFTEST(C) to #include
confdefs.h rather than prepending its contents to the test program.  This
would keep macros that bypass AC_DEFINE working, but would break with
compilers that make #pragma once do something wacky (it should be no worse
than the status quo with compilers that merely _ignore_ #pragma once). I also
wonder if there's a concrete reason why AC_LANG_CONFTEST(C) _shouldn't_
#include confdefs.h.

We should be able to get this done for 2.73.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

[Zack Weinberg]

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'
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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

[Sergei Trofimovich]

Follow-up Comment #1, sr #110382 (project autoconf):

I attempted to fix in `apr` by using `AC_LANG_PROGRAM` as
https://github.com/apache/apr/pull/25

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

[Sergei Trofimovich]

URL:
  

 Summary: In autoconf-2.69d AC_LANG_SOURCE implicitly includes
'#include "confdefs.h"'
 Project: Autoconf
Submitted by: slyfox
Submitted on: Ср 25 ноя 2020 07:53:31
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

I'm not sure if it's a bug or feature. Filing a bug to clarify. 

Initially bug is observed on apr-1.7.0 package:
https://bugs.gentoo.org/750353

Here is a small example extracted from apr source code at
https://github.com/apache/apr/blob/trunk/build/apr_common.m4#L508:


AC_PREREQ([2.59])

AC_INIT

dnl this seems to be the trigger:
AC_USE_SYSTEM_EXTENSIONS

CFLAGS="$CFLAGS -Werror"
AC_COMPILE_IFELSE(
  [AC_LANG_SOURCE(
   [#include "confdefs.h"
   int main(int argc, const char *const *argv) { return 0; }]
  )], [:], [AC_MSG_ERROR(Found warnings)])

AC_OUTPUT


Worked before as:


$ autoreconf-2.69 && ./configure --host=x86_64-pc-linux-gnu
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
configure: creating ./config.status


OK.

Fails now:


$ autoreconf-2.69d && ./configure --host=x86_64-pc-linux-gnu
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to enable C11 features... none
needed
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
configure: error: Found warnings


config.log says it happens because now "confdefs.h" is already included in
tests:


...
configure:3350: x86_64-pc-linux-gnu-gcc -c -g -O2 -Werror  conftest.c >&5
In file included from conftest.c:31:
confdefs.h:22: error: "__STDC_WANT_IEC_60559_ATTRIBS_EXT__" redefined
[-Werror]
   22 | #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
  |
...
cc1: all warnings being treated as errors
configure:3350: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define STDC_HEADERS 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _DARWIN_C_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
| #define __STDC_WANT_IEC_60559_BFP_EXT__ 1
| #define __STDC_WANT_IEC_60559_DFP_EXT__ 1
| #define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1
| #define __STDC_WANT_IEC_60559_TYPES_EXT__ 1
| #define __STDC_WANT_LIB_EXT2__ 1
| #define __STDC_WANT_MATH_SPEC_FUNCS__ 1
| #define _TANDEM_SOURCE 1
| /* end confdefs.h.  */
| #include "confdefs.h"
|int main(int argc, const char *const *argv) { return 0; }
|
configure:3354: error: Found warnings


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

Thank you!