As C23 is now mostly supported by GCC, it's time for
AC_PROG_CC to prefer C23 if available.
* lib/autoconf/c.m4 (_AC_C_C23_TEST_GLOBALS, _AC_C_C23_TEST_MAIN):
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
Problems reported by Antonin Décimo in:
https://lists.gnu.org/r/autoconf/2024-04/msg00001.html
* lib/autoconf/c.m4 (_AC_C_C89_TEST_GLOBALS):
Do not test the value of __STDC__.
(_AC_C_C99_TEST_MAIN): Do not test for VLAs.
(_AC_C_C11_OPTIONS): Also test -std:c11.
Since 2.72[abcde] did not get widely used, squash all the NEWS entries
since 2.71 together, and delete things that were only of interest to
people going from a,b,c to d to e. Finalize the release date.
On file systems with coarse-grained timestamps, this test was broken by
<https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=713d9822bbfb2923115065efaefed34a0113f8a1>,
which changed autom4te's logic for deciding whether its output file is
newer than its cache file. After that commit, if their modification
times are equal, the output is considered out of date. Since both
files are created in quick succession, on file systems with coarse
timestamps (1 or 2s resolution), it is very easy for their
modification times to be equal.
As a stopgap for 2.72, in this test, force the generated configure
script’s mtime to be newer than the cache file.
* tests/tools.at (autoconf: forbidden tokens, basic): After the
second AT_MTIME_DELAY, touch configure.
AC_SYS_YEAR2038_RECOMMENDED causes configure to fail if we can’t find
a way to activate support for 64-bit time_t. This makes its
mktests.pl test fail on systems that don’t support 64-bit time_t.
Switch to a hand-written test that’s skipped on those systems.
While I was in there I added slightly more testing of the closely
related macros AC_SYS_LARGEFILE and AC_SYS_YEAR2038.
While testing this change I noticed that AC_SYS_LARGEFILE and
AC_SYS_YEAR2038 malfunction if AC_LANG([C++]) is in effect.
The cause is too hairy to fix before the release; add a mention
to NEWS instead. (Bug <https://savannah.gnu.org/support/index.php?110983>.)
* tests/mktests.pl: Exclude AC_SYS_LARGEFILE, AC_SYS_YEAR2038, and
AC_SYS_YEAR2038_RECOMMENDED from automatic test generation.
* tests/semantics.at: Add manual tests of those macros.
Revise all NEWS entries since 2.71 for clarity. Add an entry
to the compatibility section about the macros that no longer
have AC_PROG_{EGREP,CPP} as a side effect.
New macro AC_SYS_YEAR2038_RECOMMENDED replaces new macro
AC_SYS_YEAR2038_REQUIRED, and gives the builder an out of
specifying --disable-year2038. Remove new macro
AC_SYS_LARGEFILE_REQUIRED, which was added only for symmetry and
does not seem to have a great need.
* NEWS, doc/autoconf.texi: Document this.
* lib/autoconf/specific.m4:
Be more specific about mid-January 2038 than just Jan 2038.
(_AC_SYS_YEAR2038_PROBE): Ignore IF-NOT-DETECTED arg.
If support is not detected, merely set ac_have_year2038=no instead
of erroring out. All callers changed.
(_AC_SYS_YEAR2038_OPT_IN): Remove. All callers removed.
(AC_SYS_YEAR2038): Simplify by requiring AC_SYS_LARGEFILE
and then testing the result.
(AC_SYS_YEAR2038_REQUIRED, AC_SYS_LARGEFILE_REQUIRED): Remove.
(AC_SYS_YEAR2038_RECOMMENDED): New macro.
(_AC_SYS_LARGEFILE_PROBE): If support is not detected, merely set
ac_have_largefile=no instead of erroring out. All callers changed.
Take on the burden of invoking year2038 probe as needed.
(AC_SYS_LARGEFILE): Simplify.
AC_TYPE_GETGROUPS is the last remaining use of AC_EGREP_HEADER in
stock Autoconf macros. It uses it only when cross compiling, as a
fallback from an AC_RUN_IFELSE check, testing for a bug in system
headers from the late 1980s or early 1990s, where gid_t *existed*
but the second argument to getgroups needed to be an array of int,
and this didn’t cause a compile error (i.e. the system headers
declare getgroups with no prototype or an incorrect prototype).
AC_FUNC_GETGROUPS also uses AC_RUN_IFELSE to test for obscure
problems specific to long-obsolete Unixes.
The downsides of AC_RUN_IFELSE and AC_EGREP_HEADER seem more severe
than the chances of someone compiling a current-generation program,
that uses getgroups, on an OS old enough to have one of the really
nasty bugs. Accordingly, this patch changes AC_FUNC_GETGROUPS to use
a host_os-based *blacklist* both in native and cross compilation.
This is limited to the two host_os values for which either our old
code, or Gnulib, documented a serious bug: ultrix* and nextstep*.
Currently it does not try to pin down the exact version ranges subject
to the bugs — that would require research by someone with access to
the full history of these OSes.
An incorrect guess by this blacklist can be overridden by setting
ac_cv_func_getgroups_works in config.site. AC_TYPE_GETGROUPS, for its
part, now does a series of regular old AC_COMPILE_IFELSE checks to
probe the prototype of getgroups, and considers that good enough.
While I was in there I noticed that AC_FUNC_GETGROUPS does not
AC_SUBST a documented output variable, and that the name of this
variable is misspelled in the manual.
* lib/autoconf/functions.m4 (AC_FUNC_GETGROUPS): Use AC_SEARCH_LIBS
to probe for getgroups. Use an AC_CANONICAL_HOST-based blacklist
for bug detection, not AC_RUN_IFELSE. AC_SUBST the GETGROUPS_LIB
output variable.
* lib/autoconf/types.m4 (AC_TYPE_GETGROUPS): Check only the prototype
of getgroups, using AC_COMPILE_IFELSE; do not use either AC_RUN_IFELSE
or AC_EGREP_HEADER.
* doc/autoconf.texi: Update to match. Correct misspelling of
GETGROUPS_LIB.
* tests.local.at (_AT_CHECK_ENV): Allow GETGROUPS_LIB output variable.
This macro is one of the last remaining internal uses of AC_EGREP_CPP.
It has only ever done anything useful with GCC, and GCC dropped
support for ‘traditional’ compilation in version 3.3 (released 2003)
so I do not think it is worth trying to preserve.
* lib/autoconf/c.m4 (AC_PROG_GCC_TRADITIONAL): Make into a
compatibility alias for AC_PROG_CC, similar to AC_PROG_CC_STDC.
* lib/autoconf/general.m4 (AC_EGREP_CPP): Remove stale comment.
* doc/autoconf.texi, NEWS: Document this change.
* tests/mktests.pl: Exclude AC_PROG_GCC_TRADITIONAL from
autoupdate tests.
Commit 61901a1a14 dated 2022-07-10
bumped the Perl requirement to 5.10 or later, because
commit 3a9802d601 dated 2021-08-31
added code using Time::HiRes’s ‘stat’ function, a feature
added in Perl 5.8.9+ or Perl 5.10+, and it was hard
to find Perl 5.8.9 hosts to test with. Also, requiring Perl 5.10
meant that we could then use operators like Digest::SHA, the // and
//= operators, the regexp \K escape, and ‘state’ variables.
However, that Time::HiRes code, which was taken from Automake, has
recently been made optional by Automake, and it now works again with
Perl 5.6. And Autoconf is not yet using any other post-5.6 feature,
except when developers run help-extract.pl (something Autoconf users
do not use). So relax the Autoconf user requirement back to 5.6 as it
was in Autoconf 2.71; although Autoconf developers will need 5.10 or
better, Autoconf users can get by with 5.6.
I ran into this problem when testing the Autoconf release candidate on
Solaris 10, which has Perl 5.8.4. Oracle says Solaris 10’s
end-of-life is January 2024, so it’s still (barely) a viable porting
target. Of course with Solaris 10 one must install a recent-enough
GNU m4, but adding a requirement to also install a recent-enough Perl
is a new barrier, and if it’s not needed then it might be better to
wait until it is needed (or until 2024 arrives).
* NEWS: Update news item about Perl 5.6 vs 5.10.
* README-hacking: Bump Perl recommendation to 5.10.
* build-aux/fetch.pl: Do not munge imported code to require 5.10.
* NEWS, doc/autoconf.texi (System Services):
Improve documentation for behavior of largefile and year-2038 support.
Say that in the current implementation, year-2038 support
requires largefile support. Say that year-2038 support
matters only for GNU/Linux glibc 2.34+ on 32-bit x86 and ARM.
Prefer brevity when this does not hurt understandability;
for example, prefer active to passive voice.
Prefer “wider” to “larger” when talking about the number of
bits in an integer, as this terminology is more standard.
Tone down the wording in warnings about enabling year-2038 support,
use similar wording in warnings about enabling largefile support,
and warn also about disabling largefile and year-2038 support.
No need for @emph. Also mention rlim_t.
Be a bit more careful about saying “2 GiB” rather than “2 GB”.
Mention that a future version of Autoconf might change
AC_SYS_LARGEFILE to default to --enable-year2038, since
something has gotta happen before 2038.
Coalesce descriptions of --enable-largefile and --enable-year2038
to simplify documentation. Mention that the only system where
AC_SYS_LARGEFILE changes CC is IRIX and that these systems
are obsolete. Say that ‘stat’ can fail due to time_t
overflow. Say that you can’t portably print time_t with %ld.
Say that binary compatibilty problems also can occur when one
library is linking to amother; it’s not just apps vs libraries.
Mention the possibility of modifying libraries to support both
32- and 64-bit interfaces. Warn more consistently about
ABI compatibility issues, but put the bulk of this text
in one location that the other locations refer to.
They are not needed for Gnulib, and users have an easy way to get
their effect, so for now omit them and just document the easy way.
Also, redo documentation to make it clear that AC_YEAR_2038 is
like AC_SYS_LARGEFILE except with a different year-2038 default.
* NEWS, doc/autoconf.texi: Document the above.
* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_REQUIRED):
(AC_SYS_LARGEFILE_REQUIRED): Remove. Remove some support code.
Perhaps further simplification could be done but I quit while
I was ahead.
Having AC_SYS_LARGEFILE enlarge time_t means that any program that has
already requested large file support will be abruptly migrated to
64-bit time_t (on 32-bit systems) as soon as its configure script is
regenerated with a sufficiently new Autoconf. We’ve received reports
of several widely used programs and libraries that are not prepared
for this migration, with breakage ranging from annoying (garbage
timestamps in messages) through serious (binary compatibility break
in security-critical shared library) to catastrophic (on-disk data
corruption).
Partially revert f6657256a3: in the
absence of AC_SYS_YEAR2038, AC_SYS_LARGEFILE will now only add an
--enable-year2038 command line option to configure. If this option is
used, time_t will be enlarged, allowing people to experiment with the
migration without needing to *edit* the configure script in question,
only regenerate it.
In the process, AC_SYS_LARGEFILE and AC_SYS_YEAR2038 were drastically
overhauled for modularity; it should now be much easier to add support
for platforms that offer large off_t / time_t but not with the standard
feature selection macros. Also, new macros AC_SYS_LARGEFILE_REQUIRED and
AC_SYS_YEAR2038_REQUIRED can be used by programs for which large off_t /
time_t are essential.
The implementation is a little messy because it needs to gracefully
handle the case where AC_SYS_LARGEFILE and AC_SYS_LARGEFILE_REQUIRED
are both used in the same configure script — or, probably more common,
AC_SYS_LARGEFILE (which invokes _AC_SYS_YEAR2038_OPT_IN) followed by
AC_SYS_YEAR2038 — but if macro B is invoked after macro A, there’s no
way for B to change *what macro A expanded to*. The best kludge I
managed to find is to AC_CONFIG_COMMANDS_PRE as a m4-level hook that
sets shell variables in an early diversion.
* lib/autoconf/functions.m4 (AC_FUNC_FSEEKO): Rewrite to avoid dependency
on internal subroutines of AC_SYS_LARGEFILE.
* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_TEST_INCLUDES): Renamed to
_AC_SYS_YEAR2038_TEST_CODE.
(_AC_SYS_YEAR2038): Refactor into subroutines: _AC_SYS_YEAR2038_OPTIONS,
_AC_SYS_YEAR2038_PROBE, _AC_SYS_YEAR2038_ENABLE.
(AC_SYS_YEAR2038): Update for refactoring.
(_AC_SYS_YEAR2038_OPT_IN): New sorta-top-level macro, for use by
AC_SYS_LARGEFILE, that probes for large time_t only if the
--enable-year2038 option is given.
(AC_SYS_YEAR2038_REQUIRED): New top-level macro that insists on
support for large time_t.
(_AC_SYS_LARGEFILE_TEST_INCLUDES): Renamed to _AC_SYS_LARGEFILE_TEST_CODE.
(_AC_SYS_LARGEFILE_MACRO_VALUE, AC_SYS_LARGEFILE): Refactor along same
lines as above: _AC_SYS_LARGEFILE_OPTIONS, _AC_SYS_LARGEFILE_PROBE,
_AC_SYS_LARGEFILE_ENABLE. Invoke _AC_SYS_YEAR2038_OPT_IN at end of
_AC_SYS_LARGEFILE_PROBE. MinGW-specific logic moved to YEAR2038
macros as it has nothing to do with large file support.
(AC_SYS_LARGEFILE_REQUIRED): New top-level macro that insists on
support for large off_t.
* tests/local.at (_AT_CHECK_ENV): Also allow changes in CPPFLAGS,
enableval, enable_*, withval, with_*.
* doc/autoconf.texi, NEWS: Update documentation to match above changes.
Fix typo in definition of @dvarv.
In documentation and comments, prefer the more-common “C89” to the
equivalent “C90”, and use 2-digit years for C standards as that’s
common usage. Remove some confusing old doc for pre-C89 systems,
as Autoconf assumes C89 or later. Mention C17 and C23 briefly.
Improve doc for malloc, realloc.
* lib/autoconf/programs.m4 (AC_PROG_MKDIR_P):
Fall back on mkdir -p instead of on a relative path to
install-sh, as the latter now seems to be more of a problem
than the former.
This change is taken from Gnulib, and is needed for apps like GDB.
* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_TEST_INCLUDES)
(_AC_SYS_YEAR2038, AC_SYS_YEAR2038): New macros, taken (with
renaming) from Gnulib.
(_AC_SYS_LARGEFILE_MACRO_VALUE): #undef before #define.
(AC_SYS_LARGEFILE): Prefer AS_IF and AS_CASE to doing it by hand.
Widen time_t if possible, too. Define __MINGW_USE_VC2005_COMPAT
early if needed.
Tests of AC_{CHECK_,}HEADER_STDBOOL were failing on Darwin for two
reasons: an m4 quoting bug in tests/local.at causing Darwin sed to
throw syntax errors, and an excessively precise interpretation of how
C99 and C++11 interact. The latter is worth mentioning in NEWS.
* tests/local.at (_AT_DEFINES_CMP_PRUNE): Insert [] before ‘dnl’ in
two places to keep it separate from the result of the m4_bpatsubsts
operation that immediately precedes it.
* lib/autoconf/headers.m4 (AC_CHECK_HEADER_STDBOOL): Allow ‘bool’,
‘true’, and ‘false’ not to be macros, after including stdbool.h,
whenever __cplusplus is defined.
* NEWS: Document change to AC_{CHECK_,}HEADER_STDBOOL.
The minimum Perl version was raised to 5.8.0 from 5.6.0 in commit
3a9802d601 (but not documented as
such until e8c2d79ec4, and not
actually *enforced* by our own configure script until, er, now)
in order to use Time::HiRes::stat.
Unfortunately, while the Time::HiRes *module* was added in 5.8.0, it
did not export a ‘stat’ function until 5.8.9. More precisely, this
feature was added to Time::HiRes in version 1.92 of that module; Perl
core 5.8.8 shipped Time::HiRes 1.86, 5.8.9 shipped 1.9715. The only
system I have convenient access to, that has older Perls installed,
offers me a choice of 5.8.8 or 5.10.1, so the new requirement means
I cannot test with 5.8.x anymore.
Per https://perldoc.perl.org/perlhist the release history of these
versions of Perl is, in chronological order,
5.8.0 2002-Jul-18
5.8.8 2006-Jan-31
5.10.0 2007-Dec-18
5.8.9 2008-Dec-14 <-- almost a year later than 5.10.0
5.10.1 2009-Aug-22
5.12.0 2010-Apr-12
Per https://perldoc.perl.org/perl5101delta the differences between
5.10.0 and 5.10.1 are small, and do not make me worry about
accidentally introducing code that works on my test boxes but not for
our users, unlike the gulf between 5.8.x and 5.10.x.
Requiring 5.10 will mean that we have access to Digest::SHA, the //
and //= operators, the regexp \K escape, and ‘state’ variables
(lexical scope, persistent value) all of which I can think
of uses for (but none of them are actually used in this patch).
Putting it all together, I think a requirement bump to version 5.10.0
is justified. We are already chopping off the trailing edge at 2006
due to the requirement for M4 1.4.8 (/de facto/ since 2.70) and late
2007 is still 15 years ago.
This patch also makes configure search $PATH for executables named
‘perl5*’ and ‘perl-5.*’ if bare ‘perl’ is too old. To do this, it
introduces a helper macro AClocal_PATH_PROG_GLOBS_FEATURE_CHECK, which
I would *like* to promote to a new Autoconf feature, but I got stuck
on quoting issues — see comments in m4/perl-time-hires.m4.
* NEWS: Document requirement for Perl 5.10.
* m4/perl-time-hires.m4: New file.
* configure.ac: Use AC_PATH_PERL_WITH_TIME_HIRES_STAT to probe for
perl.
* build-aux/fetch.pl (fetch): For .pm files fetched from Automake,
rewrite “use 5.006” to “use 5.010”.
* build-aux/help-extract.pl
* lib/Autom4te/C4che.pm
* lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm
* lib/Autom4te/Config.pm
* lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm
* lib/Autom4te/General.pm
* lib/Autom4te/Getopt.pm
* lib/Autom4te/Request.pm
* lib/Autom4te/XFile.pm
* tests/mktests.pl: Change “use 5.006” to “use 5.010”.
The former minimum version was 1.4.6. 1.4.6 and 1.4.7 do not track
the original location of text fed to ‘m4wrap’, which breaks autom4te’s
ability to trace macros invoked from _AC_FINALIZE.
Right now, the only _user_ visible effect of this is that autoconf
running on M4 1.4.6 or 1.4.7 will emit an internal error, instead of
the intended warning message, when it processes a configure.ac that
neglects to invoke AC_INIT or AC_OUTPUT. Perhaps more importantly,
it causes a bunch of scary-sounding failures in our own testsuite,
which deliberately doesn’t use AC_OUTPUT sometimes.
M4 1.4.6 and 1.4.7 also have bugs in location tracking of macro
invocations spread over multiple lines, which, guess what, causes
even more testsuite failures.
1.4.8 came out in 2006. As a practical matter, this change to our
requirements means that people using macOS *to run autoconf* (not just
to run generated configure scripts) cannot use the system-provided m4
anymore. {Free,Net,Open}BSD already don’t ship GNU M4 as their system
m4, so users of those OSes should not be affected.
Autoconf’s diagnostics now follow current GNU coding standards,
which say that diagnostics in the C locale should quote 'like this'
with plain apostrophes instead of the older GNU style `like this'
with grave accent and apostrophe.
Matching the commits on the release branch:
* NEWS: Bring over record of release notes.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
Since 1993, Autoconf has been assuming that it is safe to include any
of the headers defined by ISO C90 without checking for them; this is
inaccurate, since only a subset are necessarily available in a
C90 *freestanding* environment.
It is OK to assume the presence of a header in a macro that checks
specifically for something declared by that header (if the header is
not present, we will think the specific declaration is unavailable,
which is probably accurate for modern embedded environments). It is
also OK to continue recommending that user code use these headers
unconditionally—anyone working with a freestanding environment knows
it. But it is not OK for very generic code within Autoconf itself,
such as AC_INCLUDES_DEFAULT, to make this assumption.
Note that the set of headers that are not always available includes
stdio.h, which we have been assuming can be included unconditionally
for even longer.
In AC_INCLUDES_DEFAULT, revert to checking for string.h and stdlib.h
before including them. Also revert to defining STDC_HEADERS only when
string.h and stdlib.h are available (but do not check for float.h and
stdarg.h, as these are part of the freestanding set). Add a new check
for stdio.h. Sort the inclusion list by standard (C90 freestanding;
C90 hosted; C99; POSIX) and alphabetically within each group. Revise
all the documentation and update the testsuite.
This partially reverts commit 86c213d0e3
and is a partial fix for bug #110393.
* lib/autoconf/headers.m4 (AC_CHECK_INCLUDES_DEFAULT): Check for
stdio.h, stdlib.h, and string.h before including them. Define
STDC_HEADERS only when string.h and stdlib.h are both available.
Organize includes list by standard, then alphabetically.
* doc/autoconf.texi, NEWS: Update to match.
* tests/local.at (AT_CHECK_DEFINES): Make regexes more specific.
Also expect a definition of HAVE_STDIO_H.
* tests/c.at, tests/semantics.at, tests/tools.at: Use <float.h>,
not <stdio.h>, as a header that we expect always to exist.
Add HAVE_STDIO_H to various lists of macros that are expected to
appear in config.h.
Revert commit 18c140b50b, restoring
AC_PROG_CC to being defined as an ordinary AC_DEFUN. This broke
third-party macros (e.g. the Autoconf Macro Archive’s
AX_PROG_CC_FOR_BUILD) that intentionally invoked AC_PROG_CC a second
time with its guts redefined via a whole bunch of ‘pushdef’s. I don’t
think we want to support this long-term, but needing access to a
build-native compiler in cross-compilation is common enough that we
should have *some* supported way to do it, and it may as well be
AX_PROG_CC_FOR_BUILD until we come up with something better.
If we go back to AC_DEFUN_ONCE for AC_PROG_CC in the future, we should
do it consistently for all the “find me a compiler” macros -- it
was *only* done for AC_PROG_CC in 18c140b5.
The rationale for AC_DEFUN_ONCE seems to have been to reduce the size
of the generated configure script. The bulk of the size accountable to
AC_PROG_CC is the test programs for figuring out which version of the
C standard is available, so I tweaked _AC_C_STD_TRY (and _AC_CXX_STD_TRY)
to emit that text only once per program, into shell variables which
can then be referenced repeatedly.
Fixes bug #110350.
* NEWS, doc/autoconf.texi: Revert documentation changes associated
with AC_PROG_CC being a one-shot macro.
* lib/autoconf/c.m4 (AC_PROG_CC): Revert to defining with AC_DEFUN.
(_AC_C_STD_TRY, _AC_CXX_STD_TRY): Emit the test program only once,
even if invoked multiple times with the same arguments.
* tests/foreign.at (AX_PROG_CC_FOR_BUILD, AX_PROG_CXX_FOR_BUILD):
New tests.
Currently, there isn’t any documented way for an Autotest testsuite to
add custom code to be run either right before the main driver loop, or
at the point of each AT_SETUP. For instance, there’s no good place to
put environment variable sanitization that should apply to the entire
testsuite (but isn’t universally relevant), or shell function
definitions to be used by custom test macros.
Autoconf’s test suite is poking shell functions directly into the
PREPARE_TESTS diversion, and doing environment variable sanitization
in each individual test. Both of these are obviously undesirable.
This patch adds three new AT_* macros that can be used to do these
things in an officially-supported way: AT_PREPARE_TESTS adds code to
be run right before the main driver loop, AT_PREPARE_EACH_TEST adds
code to be run at the beginning of each test, and AT_TEST_HELPER_FN
defines a shell function that will be available to each test. In
Autoconf’s test suite, I use AT_PREPARE_TESTS to factor out
environment variable sanitization that *ought* to apply across the
board, and AT_TEST_HELPER_FN for the helper function used by
AT_CHECK_ENV.
(This fixes the testsuite bug reported by Jannick at
https://lists.gnu.org/archive/html/autoconf/2020-10/msg00052.html :
CONFIG_SITE in the parent environment will no longer be visible to tests.)
It would be nice to give an example of when AT_PREPARE_EACH_TEST is
useful, in the documentation, but I didn’t find one in the autoconf
test suite.
* lib/autotest/general.m4 (AT_PREPARE_TESTS, AT_PREPARE_EACH_TEST)
(AT_TEST_HELPER_FN): New macros.
(AT_INIT, AT_TESTED): Emit the code to report tested programs only
if it’s needed, and make sure it’s after any code added by
AT_PREPARE_TESTS.
* tests/local.at: Add AT_PREPARE_TESTS block that ensures
$MAKE is set sensibly and $MAKEFLAGS and $CONFIG_SITE are unset.
Use AT_TEST_HELPER_FN for the helper function needed by AT_CHECK_ENV.
(AT_CHECK_MAKE): No need to sanitize $MAKE or $MAKEFLAGS here.
* tests/base.at, tests/compile.at, tests/m4sh.at, tests/torture.at:
No need to unset or neutralize $CONFIG_SITE in individual tests.
* tests/autotest.at: Add tests for new macros.
* doc/autoconf.texi, NEWS: Document new macros.
Many of the reported regressions in Autoconf 2.70 betas went unnoticed
for years because Autoconf’s bundled test suite didn’t test most of
the macros with a C++ compiler and/or in cross compilation mode.
There’s a special makefile target ‘maintainer-check-c++’ that runs all
the tests with CC=g++, but that doesn’t catch the regressions either,
because it doesn’t compare the configure results with what you’d have
gotten with a C compiler. Also, C and C++ have diverged to the point
where setting CC to a C++ compiler doesn’t work reliably anymore.
This patch overhauls AT_CHECK_MACRO to test each macro four times:
(C compiler, C++ compiler) x (native mode, cross-compilation mode).
All four tests are expected to produce the same config.cache and
config.h, except for certain predictable differences due to running
AC_PROG_CXX instead of AC_PROG_CC, and a short list of known,
acceptable differences, maintained in mktests.pl.
There are two classes of known, acceptable differences. Macros that
use AC_RUN_IFELSE aren’t tested in cross-compilation mode at all,
because they may crash the script (this is temporary and will be
revisited after 2.70). Macros that correctly detect a difference
between C and C++ (e.g. AC_HEADER_STDBOOL will notice that C++ doesn’t
have the _Bool type) are annotated with the specific cache variable
and #define that varies.
mktests.pl now also has the capability to provide values for the
MACRO-USE, ADDITIONAL-COMMANDS, and AUTOCONF-FLAGS arguments to
AT_CHECK_(AU_)MACRO, on a per-macro basis, but that’s not used in this
patch.
Some of the manual uses of AT_CHECK_MACRO do not need to test C++
and/or cross compilation; for them, there is a new test helper,
AT_CHECK_CONFIGURE_AC. Another new helper, AT_PRESERVE_CONFIG_STATUS,
is used extensively in AT_CHECK_(AU_)MACRO but may be also useful in
manual tests that need to do multiple configure runs.
This change supersedes AT_CHECK_MACRO_CROSS and
‘make maintainer-check-c++’, which are removed.
In my testing, setting CC to a C++ compiler no longer works at all,
for reasons that are impractical to fix (e.g. C++ compilers choke on
the test for C2011 features) so I have added a note to NEWS saying
that this is not supported anymore.
* tests/local.at (AT_CHECK_MACRO): Default behavior is now to test
the macro in both native and cross-compilation mode, and expect the
results to be identical. If the macro transitively required
AC_PROG_CC, and a C++ compiler is available, then test it twice
more with AC_LANG([C++]) in effect, and again expect the results to
be identical. New fifth argument TEST-PARAMETERS can modify this
behavior.
(_AT_FILTER_CXX_CV_VARIES, _AT_FILTER_CXX_DEFINE_VARIES): New,
subroutines of AT_CHECK_MACRO.
(AT_CHECK_MACRO_CROSS): Remove, subsumed by new AT_CHECK_MACRO
behavior.
(AT_CHECK_AU_MACRO): Forward to AT_CHECK_MACRO for the basic test;
then do the same autoupdate test as before, as a separate test group.
(at_check_env): Also ignore OPENMP_CXXFLAGS.
(AT_CONFIG_CMP): Add third argument EXTRA-VARIANCE that specifies
additional variables that are expected to vary in a particular test.
(_AT_CONFIG_CMP_PRUNE): New, subroutine of AT_CONFIG_CMP.
(AT_DEFINES_CMP): New helper macro that compares config.h headers,
with the ability to ignore variation in specific defines.
(_AT_DEFINES_CMP_PRUNE): New, subroutine of AT_DEFINES_CMP.
(AT_PRESERVE_CONFIG_STATUS): New helper that makes copies of
config.h, config.log, config.status, and state-env.after under
names that won’t be clobbered by a subsequent run of configure.
(AT_CHECK_CONFIGURE_AC): New helper that defines a complete test
group consisting of a single invocation of _AT_CHECK_AC_MACRO;
effectively what AT_CHECK_MACRO used to be.
(_AT_CHECK_AC_MACRO): Correct documentation comment; the PRE-TESTS
argument has always been optional.
* tests/mktests.pl (test_parameters): New global data object giving
extra arguments to pass to AT_CHECK_MACRO/AT_CHECK_AU_MACRO on a
per-macro basis.
(emit_test): New function that handles emitting calls to
AT_CHECK_(AU_)MACRO with the desired arguments.
(scan_m4_files): Use emit_test.
(au_exclude_list): Add AC_HAVE_LIBRARY, AC_COMPILE_CHECK,
AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK, and AC_TRY_RUN.
* tests/semantics.at (AC_CHECK_LIB, AC_SEARCH_LIBS): Rewrite test
using symbols from zlib instead of libm, to get consistent behavior
from C and C++.
(AC_SEARCH_LIBS (none needed)): Revise to clarify what is being tested.
(AC_CHECK_DECLS): Use _AC_LANG_ABBREV when inspecting cache variables.
(AC_CHECK_ALIGNOF, AC_CHECK_ALIGNOF struct)
(AC_CHECK_SIZEOF, AC_CHECK_SIZEOF struct)
No need for AT_CHECK_MACRO_CROSS.
(AC_CHECK_FILES): Switch to AT_CHECK_CONFIGURE_AC.
(AC_SYS_RESTARTABLE_SYSCALLS, AC_FUNC_WAIT3): Do not test in cross
compilation mode.
(AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK, AC_TRY_RUN)
(AC_COMPILE_CHECK, AC_HAVE_LIBRARY): New manual AT_CHECK_AU_MACRO tests.
* tests/c.at (Extensions, C keywords, AC_PROG_CPP requires AC_PROG_CC)
(AC_NO_EXECUTABLES (working linker), AC_NO_EXECUTABLES (broken linker)):
Switch to AT_CHECK_CONFIGURE_AC. Also convert case statements to AS_CASE.
(Broken/missing compilers): Pass CC=no-such-compiler on the command
line instead of hardwiring it in the configure script.
* tests/local.mk (maintainer-check-c++): Remove target.
(maintainer-check): Run the ordinary ‘make check’ as well as
‘make maintainer-check-posix’.
AS_IF can emit a syntactically invalid shell if-then-else,
if CONDITION
then :
# ...
else
fi
when its IF-FALSE argument consists of macros that don’t produce any
shell code. This was a documented limitation in AS_IF, but it’s a bad
limitation to have, because macros that *used* to expand to shell
commands might start expanding to nothing in future releases. For
instance, this broke the libzmq configure script, which did
AC_PROG_CC
AX_CHECK_COMPILE_FLAG([-std=gnu11],
[CFLAGS+=" -std=gnu11"],
[AC_PROG_CC_C99])
Perfectly valid in 2.69, but in 2.70 AC_PROG_CC_C99 doesn’t produce
any shell code and the script crashes.
We had that limitation for good reason: we can’t just put ‘:’ at the
beginning of the else-clause, like we do for the then-clause, because
that would clobber $? and the IF-FALSE commands might want to inspect
it. (This doesn’t matter for the then-clause, because $? is always
zero at the beginning of a then-clause anyway.) The simplest and
least inefficient shell construct I can find that works in this
context is a shell function that does ‘return $?’. Due to awkward
M4sh initialization ordering constraints (AS_IF gets used before we
can safely use shell functions) an indirection through a shell
variable is necessary. The structure of a m4sh script is now
#! /bin/sh
## M4sh Initialization
as_nop=:
...
## M4sh Shell Functions
as_fn_nop () { return $?; }
as_nop=as_fn_nop
...
and AS_IF emits
if CONDITION
then :
# ...
else $as_nop
# ...
fi
The uses of AS_IF that appear before the beginning of the M4sh Shell
Functions section are all under our control and they don’t need to
look at $?.
If anyone has a better idea for how to make this work I will be glad
to hear it.
Fixes bug #110369.
* lib/m4sugar/m4sh.m4
(_AS_IF_ELSE): When $1 is nonempty, invoke _AS_EMPTY_ELSE_PREPARE.
Emit $as_nop at beginning of else clause.
(_AS_BOURNE_COMPATIBLE): Initialize as_nop to ‘:’.
(_AS_EMPTY_ELSE_PREPARE): New macro which emits a definition of
as_fn_nop and resets as_nop to as_fn_nop.
(AS_PREPARE, _AS_PREPARE): Invoke _AS_EMPTY_ELSE_PREPARE.
(_AS_UNSET_PREPARE): Tweak white space.
* tests/m4sh.at (AS_IF and AS_CASE): Test AS_IF’s IF-FALSE argument
being empty after macro expansion.
* doc/autoconf.texi (AS_IF): Remove warning about use with
‘run-if-false’ argument empty after macro expansion.
As of the 2020-11-07 update, config.sub and config.guess
unconditionally use $(...) command substitution; see
<https://lists.gnu.org/archive/html/config-patches/2020-11/msg00011.html>.
Therefore, add this to the set of required shell features, searched
for by _AS_DETECT_BETTER_SHELL. On a system where /bin/sh doesn’t
support $(...), $CONFIG_SHELL will be set to one that does (and the
primary configure script will be re-executed using that shell).
AC_CANONICAL_* use $CONFIG_SHELL to execute config.guess/sub, so they
will keep working. This also means that configure scripts and
third-party macros that use $(...) will quietly start working
correctly on such ancient systems.
The test code is simple, but sufficient to weed out Solaris 10’s
/bin/sh, which doesn’t support $(...) but *does* support shell
functions.
I’m not going to touch any of the existing uses of `...` command
substitution in Autoconf proper for now, but it might make sense to
bulk upgrade them early in the 2.71 release cycle; if nothing else,
it would remove a major obstacle to running shellcheck over our
scripts.
* lib/m4sugar/m4sh.m4 (_AS_MODERN_CMDSUBST_WORKS): New macro.
(AS_INIT, AS_SHELL_SANITIZE): Call _AS_DETECT_REQUIRED for
_AS_MODERN_CMDSUBST_WORKS.
* NEWS: Mention the requirement for $(...).
