bug-gnulib
[Top][All Lists]
Advanced

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

Don't #include gnulib-generated .h files from config.h


From: Bruno Haible
Subject: Don't #include gnulib-generated .h files from config.h
Date: Sun, 25 Sep 2022 01:10:23 +0200

With the current gnulib, I'm getting two new test failures of 'lang-c' and
'lang-c++' in GNU gettext. 'lang-c' for example fails to compile the sample
program:


FAIL: lang-c
============

prog.c
../..\config.h(3288): fatal error C1083: Cannot open include file: 
'stdalign.h': No such file or directory
FAIL lang-c (exit status: 1)


The gettext sample programs include <config.h>. On this platform, there is no
<stdalign.h>, and thus stdalign.m4 has stuffed a
  #include <stdalign.h>
into config.h, intending to include the gnulib-generated stdalign.h.

This is problematic for three reasons:

  * Since the gnulib-generated stdalign.h is in a different directory than
    config.h, the compilation command needs additional -I options. This is
    likely to occur not only in GNU gettext, but also in other packages.
    And adding such -I options may cause other generated .h files
    (stdio.h, unistd.h, etc.) to become visible, which can activate some
    rpl_ substitutes and thus cause link errors.

  * There can be several gnulib-tool invocations in the scope of a single
    configure.ac and config.h. It is not even clear to the package maintainer
    from which gnulib build directory to take stdalign.h.

  * stdalign.h is created by "make" — after config.h, which is created by
    config.status. And similarly, "make clean" erases stdalign.h but not
    config.h. So, for some time, we have a config.h file which includes a
    nonexistent file. This too can cause all sorts of trouble that will
    be difficult to track down by the package maintainer.

Thus, it's best to avoid such a situation. This holds not only for
<stdalign.h> but also for <stdbool.h>. For <assert.h> on the other hand
I think the trouble is limited, because <assert.h> always exists among the
system header files.

The attached patches do this. Note that this raises a question how to get
along with an AC_C_BOOL macro, since obviously Autoconf cannot be kept
in sync with Gnulib. Maybe AC_C_BOOL will need to take an optional argument
AC_C_BOOL([substitute for stdbool.h]) ?


2022-09-24  Bruno Haible  <bruno@clisp.org>

        stdbool: Don't #include a gnulib-generated stdbool.h from config.h.
        * m4/c-bool.m4 (gl_C_BOOL): Check for stdbool.h and for _Bool. If
        stdbool.h does not exist, don't #include <stdbool.h> but instead put the
        substitute code into config.h.

2022-09-24  Bruno Haible  <bruno@clisp.org>

        stdalign: Don't #include a gnulib-generated stdalign.h from config.h.
        * m4/stdalign.m4 (gl_STDALIGN_H): Check for stdalign.h. If it does not
        exist, don't #include <stdalign.h> but instead put the substitute code
        into config.h.

Attachment: 0001-stdalign-Don-t-include-a-gnulib-generated-stdalign.h.patch
Description: Text Data

Attachment: 0002-stdbool-Don-t-include-a-gnulib-generated-stdbool.h-f.patch
Description: Text Data


reply via email to

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