This is useful for GNU Emacs, which still ports to that
old Android version. The change here is imported from Gnulib.
* lib/autoconf/functions.m4 (AC_FUNC_STRNLEN):
Also detect Android 5.0 bug. Use AC_COMPILE_IFELSE rather
than AC_CANONICAL_HOST for cross-compile test.
Inspired by Collin Funk’s suggestion in:
https://lists.gnu.org/r/autoconf-patches/2024-06/msg00000.html
* bin/autom4te.in (handle_output):
* bin/autoscan.in, bin/ifnames.in (scan_c_file):
Also recognize #elifdef and #elifndef.
* tests/tools.at (ifnames): Test it for ifnames.
The recent glitch with C++11 underscores the fact that it’s
long past time for Autoconf to catch up with the C++ standards.
Add simple tests for each iteration of the C++ standard.
They can be improved later as needed. When testing for these
newer standards, do not also test for features required by earlier
standards, as this isn’t all that helpful, leads to an O(N**2)
growth of ‘configure’, and can result in problems such as the
C++11 vs C++20 bug recently fixed.
* lib/autoconf/c.m4 (_AC_CXX_CXX14_TEST_PROGRAM)
(_AC_CXX_CXX17_TEST_PROGRAM, _AC_CXX_CXX20_TEST_PROGRAM)
(_AC_CXX_CXX23_TEST_PROGRAM, _AC_CXX_CXX14_OPTIONS)
(_AC_CXX_CXX17_OPTIONS, _AC_CXX_CXX20_OPTIONS)
(_AC_CXX_CXX23_OPTIONS): New macros.
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
(_AC_PROG_CXX_STDCXX_EDITION): Use them.
Trivial fix suggested by Peter Johansson in:
https://lists.gnu.org/r/autoconf/2024-05/msg00004.html
* lib/autoconf/c.m4 (_AC_CXX_CXX11_TEST_MAIN):
Do not test assigning u8"..." to char const *, as this
runs afoul of C++20.
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.
