]> git.ipfire.org Git - thirdparty/autoconf.git/commit
Use -fno-builtin, not -Werror, in AC_CHECK_DECLS (#110400)
authorZack Weinberg <zackw@panix.com>
Wed, 23 Dec 2020 17:14:06 +0000 (12:14 -0500)
committerZack Weinberg <zackw@panix.com>
Wed, 23 Dec 2020 19:06:12 +0000 (14:06 -0500)
commitde36ccf6637974f4faba3747813d38ee46e77d69
tree05ffd82b1731262006b5831e2bb0570e30f3a52e
parent616480956de06e32526775c8b7f8fd34d04238a5
Use -fno-builtin, not -Werror, in AC_CHECK_DECLS (#110400)

clang issues only a warning, not an error, when an undeclared
identifier that names a built-in function is used: for instance

    char *(*p)(const char *, int) = strchr;

(with no `#include <string.h>`) is an error with most compilers,
a warning with clang.  This broke the 2.69 implementation of
AC_CHECK_DECL.  In commit 82ef7805faffa151e724aa76c245ec590d174580,
we tried to work around this quirk by using -Werror, but that put us
at risk of being tripped up by other warnings.  Bug 110400 reports,
for instance, that this fragment (which is roughly what you get, after
preprocessing, when AC_CHECK_DECL is applied to a function that *is*
properly declared)

    extern void ac_decl (int, char *);
    int main (void)
    {
      (void) ac_decl;
      ;
      return 0;
    }

provokes a warning from clang (and thus an error) when -Wextra-semi-stmt
has been added to CFLAGS earlier in the configure script.  The extra
semicolon comes from AC_LANG_PROGRAM, and we can’t get rid of it
because we have no way of telling reliably when someone wrote
something like

    AC_LANG_PROGRAM([[#include <stdio.h>]],
                    [[puts("hello world")]])

with no semicolon at the end of the statement; this has been
acceptable for decades.  Besides, that’s just one warning, who knows
what compilers will start complaining about tomorrow?

So: change AC_CHECK_DECL to compile its programs with -fno-builtin,
instead, when the default compilation mode fails to detect an
undeclared strchr.  The code is restructured so that we can try other
options as well, if we find another compiler with the same quirk but
different command-line syntax.

(All of this logic is very C-family specific, but it appears to me
that AC_CHECK_DECL has never worked with other languages, so we can
continue to live with that for now.)

Fixes bug 110400; partially reverts 82ef7805faffa151e724aa76c245ec590d174580.

 * lib/autoconf/general.m4 (_AC_UNDECLARED_WARNING): Rename to
   _AC_UNDECLARED_BUILTIN.  Instead of looking at diagnostic output,
   loop trying to find a command-line option that makes the compiler
   error out on undeclared builtins.
   (_AC_CHECK_DECL_BODY): Don’t AC_REQUIRE anything here.
   Make shell code language-agnostic, except for the actual test program.
   Add arguments to the shell function for additional compiler options
   to use.
   (AC_CHECK_DECL): AC_REQUIRE _AC_UNDECLARED_BUILTIN here.
   Supply $ac_{AC_LANG_ABBREV}_undeclared_builtin_options to
   ac_fn_check_decl.

 * tests/local.at (AT_CONFIG_CMP): Update list of variables to ignore
   when comparing C and C++ configure runs.
 * tests/semantics.at (AC_CHECK_DECLS): Add memcpy and strchr to
   AC_CHECK_DECLS call for functions that may be known to the compiler.

 * doc/autoconf.texi (AC_CHECK_DECL, AC_CHECK_DECLS): Remove note
   about compiler warnings.
doc/autoconf.texi
lib/autoconf/general.m4
tests/local.at
tests/semantics.at