-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
We are pleased to announce stable release 2.72 of GNU Autoconf.
2.72 consists largely of bug fixes. The most significant changes are
support for the upcoming 2024 edition of the C standard (aka â??C23â??)
and a mechanism for enabling 64-bit time_t on 32-bit platforms
(--enable-year2038). See the NEWS below for a brief summary.
There have been 171 commits by 17 people in the 151 weeks since 2.71.
Thanks to everyone who has contributed:
Andreas K. Hüttel (1)
Ben Elliston (1)
Bruno Haible (8)
Detlef Riekenberg (1)
Emanuele Giaquinta (2)
Eric Blake (4)
Gleb Fotengauer-Malinovskiy (1)
Jim Meyering (5)
KO Myung-Hun (1)
Keno Fischer (1)
Marshall Ward (1)
Mike Frysinger (1)
Paul Eggert (84)
Sergei Trofimovich (1)
Todd C. Miller (1)
Xi Ruoyao (1)
Zack Weinberg (57)
We would also like to thank everyone who submitted bug reports,
whether or not we were able to resolve them:
Alain Knaff
D. Lang
David Allsopp
Dominik Kummer
E. Johnson
G. Herfray
Guillem Jover
Jacob Bachmeyer
James â??the pedantâ??
Johan Olsson
Jonathan Birge
Joshua Root
Jörn Heusipp
Marvin Scholz
Maxim Cournoyer
Michael Orlitzky
Michal Nowak
Natanael Copa
Peter Eisentraut
R. Diez
Remi Attab
Ross Burton
Sam James
Vadim Zeitlin
Valery Ushakov
Zlobin Nikita
and at least 14 more people who wished to remain anonymous.
zw
[on behalf of the autoconf maintainers]
==================================================================
Here is the GNU autoconf home page:
http://gnu.org/s/autoconf/
For a summary of changes and contributors, see:
http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=v2.72
or run this command from a git-cloned autoconf directory:
git shortlog v2.71..v2.72
Here are the compressed sources:
https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.gz (2.1MB)
https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.xz (1.4MB)
Here are the GPG detached signatures:
https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.gz.sig
https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
396c8236b777eabf7491a352c967d0f41465e06a autoconf-2.72.tar.gz
r7GBp24e5ygy9lgcDt343wMrg+LgI573nr7cRGfZLW4= autoconf-2.72.tar.gz
1d082d999ff4506ec8f92c6ecb9732546f5204fb autoconf-2.72.tar.xz
uohcExlXjWyU1G6bDc60AUyq/iSQ5Deg28o/JwoiP1o= autoconf-2.72.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify autoconf-2.72.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa4096 2010-01-14 [SC]
82F8 54F3 CE73 174B 8B63 1740 91FC C32B 6769 AA64
uid Zack Weinberg <zackw@xxxxxxxxx>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key zackw@xxxxxxxxx
gpg --recv-keys 91FCC32B6769AA64
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=autoconf&download=1' | gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify autoconf-2.72.tar.gz.sig
This release was bootstrapped with the following tools:
Automake 1.16.5
NEWS
* Noteworthy changes in release 2.72 (2023-12-22) [release]
** Backward incompatibilities
*** Configure scripts no longer support pre-1989 C compilers.
Specifically, compilers that *only* implement the original â??K&Râ??
function definition syntax, and not the newer â??prototypedâ?? syntax,
will not be able to parse the test programs now emitted by
AC_CHECK_FUNC, AC_LANG_CALL, and similar macros. AC_PROG_CC still
accepts such compilers, but this may change in the near future.
This change was necessary in order to support the upcoming 2024
edition of the C standard (often referred to as â??C23â??), which will
officially remove the function declaration syntax used by
AC_CHECK_FUNC in Autoconf 2.71 and earlier. We feel that support
for compilers that support only C 2024 is more useful, nowadays,
than support for compilers that donâ??t implement a core feature of
C 1989.
*** Autoconf developers now need Perl 5.10 (2007) or later.
â??Autoconf developersâ?? means specifically people hacking on Autoconf
itself. Autoconf *users*, i.e. authors of configure.ac files and
add-on M4 macros, still need only Perl 5.6 (2000) or later.
We do recommend all Autoconf users upgrade to Perl 5.10 or later if
possible, as this version significantly improves Perlâ??s ability to
handle files with last-modification timestamps separated by less
than a second. (Note: even in the most recent release, Perl cannot
always match the file systemâ??s timestamp resolution.)
Generated configure scripts continue to run without Perl.
*** Autoconf users now need GNU M4 1.4.8 (2006) or later.
Use of GNU M4 1.4.16 or later is recommended, as all earlier versions
are known to have had serious bugs in the text-processing builtins
on some, but not all, operating systems. Autoconfâ??s own configure
script will attempt to find a version of M4 that is not affected by
these bugs.
Note: Autoconf 2.70 and 2.71 include code that malfunctions with
M4 1.4.6 or 1.4.7. However, the only effect of the malfunction is
that you will get a confusing error message if you run autoconf on
a configure.ac that neglects to use AC_INIT or AC_OUTPUT.
Generated 'configure' scripts continue to run without M4.
*** Some m4sh diversions have been renumbered.
This will only affect macros that use m4_divert with numbered rather
than named diversions, which has always been strongly discouraged
both by the documentation and with warnings.
*** AC_FUNC_GETGROUPS and AC_TYPE_GETGROUPS no longer run test programs.
These macros were testing for OS bugs that we believe are at least
twenty years in the past. Most operating systems are now trusted to
provide an accurate prototype for getgroups in unistd.h, and to
implement it as specified in POSIX.
AC_FUNC_GETGROUPS still includes a short block-list of OSes with
known, severe bugs in getgroups. It can be overridden using
config.site. If you encounter a mistake in this list,
please report it to bug-autoconf.
*** All internal uses of AC_EGREP_CPP and AC_EGREP_HEADER have been removed.
These macros look for text matching a regular expression in the
output of the C preprocessor. Their use has been discouraged for
many years, as they tend to be unreliable; it is better to find a
way to use AC_COMPILE_IFELSE or AC_PREPROC_IFELSE instead. We have
finally taken our own advice.
This change might break configure scripts that expected probes for
â??grepâ?? and/or the C preprocessor to happen as a side effect of an
unrelated operation. Such scripts can be fixed by adding
AC_PROG_EGREP and/or AC_PROG_CPP in an appropriate place.
The macros affected by this change are AC_C_STRINGIZE,
AC_C_VARARRAYS, AC_FUNC_GETGROUPS, AC_FUNC_GETLOADAVG,
AC_HEADER_TIOCGWINSZ, AC_PROG_GCC_TRADITIONAL, AC_TYPE_GETGROUPS,
AC_TYPE_UID_T, and AC_XENIX_DIR. Many of these macros are themselves
obsolete; if your configure script uses any of them, check whether
it is actually needed.
** New features
*** Support for ensuring time_t is Y2038-safe
configure can now ensure that time_t can represent moments in time
after 18 January 2038, i.e. 2**31 - 1 seconds after the Unix epoch.
On most â??64-bitâ?? systems this is true by default; the new feature
is detection of systems where time_t is a 32-bit signed integer by
default, *and* there is an alternative mode in which it is larger,
in which case that mode will be enabled.
In this release, all configure scripts that use AC_SYS_LARGEFILE
gain a new command line option --enable-year2038. When this option
is used, the configure script will check for and enable support for
a large time_t.
This release also adds two new macros, AC_SYS_YEAR2038 and
AC_SYS_YEAR2038_RECOMMENDED. Both have all the effects of
AC_SYS_LARGEFILE. (This is because it is not possible to enlarge
time_t without also enlarging off_t, on any system we are aware of.)
AC_SYS_YEAR2038 additionally flips the default for --enable-year2038;
a configure script that uses this macro will check for and enable
support for a large time_t by default, but this can be turned off by
using --disable-year2038. AC_SYS_YEAR2038_RECOMMENDED goes even
further, and makes the configure script fail on systems that do not
seem to support timestamps after 18 January 2038 at all. This
failure can be suppressed by using --disable-year2038.
Changing the size of time_t can change a libraryâ??s ABI. Therefore,
application and library builders should take care that all packages
are configured with consistent use of --enable-year2038 or
--disable-year2038, to ensure binary compatibility. This is similar
to longstanding consistency requirements with --enable-largefile and
--disable-largefile.
In this release, these macros only know how to enlarge time_t on two
classes of systems: 32-bit MinGW, and any system where time_t can be
enlarged by defining the preprocessor macro _TIME_BITS with the
value 64. At the time this NEWS entry was written, only GNU libc
(version 2.34 and later) supported the latter macro. Authors of
other C libraries with a 32-bit time_t are encouraged to adopt
_TIME_BITS, rather than inventing a different way to enlarge time_t.
*** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions
by defining __STDC_WANT_IEC_60559_EXT__.
** Obsolete features and new warnings
*** Autoconf now quotes 'like this' instead of `like this'.
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.
*** AC_PROG_GCC_TRADITIONAL no longer does anything.
This macro has had no useful effect since GCC dropped support for
traditional-mode compilation in version 3.3 (released in 2003), and
the systems that needed it are also long obsolete. It is now a
compatibility synonym for AC_PROG_CC.
** Notable bug fixes
*** autom4te now uses fine-grained file timestamps
Autoconfâ??s internal â??autom4teâ?? utility is now able to compare file
modification timestamps with sub-second precision, when available.
This eliminates a class of bugs where autom4te fails to regenerate
an outdated file. Automake 1.17 (forthcoming) is required for a
complete fix.
*** AC_HEADER_STDBOOL, AC_CHECK_HEADER_STDBOOL are obsolescent and less picky.
These macros are now obsolescent, as most programs can simply include
stdbool.h unconditionally. If you use these macros, they now accept
a stdbool.h that exists but does nothing, so long as â??boolâ??, â??trueâ??,
and â??falseâ?? work anyway. This is for compatibility with C23 and
with C++.
*** AC_PROG_MKDIR_P now falls back on plain 'mkdir -p'.
When AC_PROG_MKDIR_P cannot find a mkdir implementation that is
known to lack race condition bugs, it now falls back on 'mkdir -p'
instead of falling back on a relative path to install-sh, as the
relative paths now seem to be a more important problem than the
problems of ancient mkdir implementations with race condition bugs.
See <https://savannah.gnu.org/support/?110740>. The only ancient
mkdir still supported is Solaris 10 /usr/bin/mkdir, and for that
platform AC_PROG_MKDIR_P falls back on /opt/sfw/bin/mkdir which
should work if it is installed; if not, you should avoid parallel
'make' on that platform.
*** Better diagnostics for calling m4_warn() with a bad first argument
Calling m4_warn with a first argument that doesnâ??t match any of the
official warning categories now produces a sensible error message,
instead of something that makes it look like thereâ??s a bug in the
guts of autom4te. Also, the documentation has been adjusted in
several places to make it clearer what the official warning
categories are.
Note: In Autoconf 2.69 and earlier, the manual said that [] and [all]
could be used as the first argument to m4_warn. This was incorrect,
even at the time.
*** Improved compatibility with a wide variety of systems and tools
including CheriBSD, Darwin (macOS), GNU Guix, OS/2, z/OS, Bash 5.2,
the BusyBox shell and utilities, Clang/LLVM version 16, the upcoming
GCC version 14, etc.
** Known bugs
*** AC_SYS_LARGEFILE and AC_SYS_YEAR2038 only work correctly in C mode.
This is only a problem for configure scripts that invoke either
macro while AC_LANG([something other than C]) is in effect, and
will only be a *visible* problem on systems where support
for large files and/or timestamps after 2038 are *available*
but not enabled by default.
This is the cause of the AC_SYS_LARGEFILE, AC_SYS_YEAR2038, and/or
AC_SYS_YEAR2038_RECOMMENDED testsuite failures on some systems.
See <https://savannah.gnu.org/support/index.php?110983> for details
and a workaround.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEgvhU885zF0uLYxdAkfzDK2dpqmQFAmWF3v8ACgkQkfzDK2dp
qmQ/CQ//Ybl06LtBn4diayvcs7SjcUkozk4Vl/2USaAIS2xT4hT9f4nnVemFrxcJ
CYgIjeIyJ3O86FxUvbZbRwPGwmfddZboevNgP9loNC+ziwsvja6V3SYxZ7uYPc5R
E8YaPXfwzwpRfxE82QYlVWKA9032keFXJLueOgemvjdAzN9jq7uQkSpfOQ5DmvLl
fH7a5UYytIBFsJ9+PAa7SBe22Kjz+IH45IocLcQX5rYDE8KwcyxfV7ysjC7zag6x
VX7L+Wgh34718VWf67ocY2KgdosnaIxEx1+eTe5mBUzfsK+MlbDCw/7apmQSGwi0
uMustzjIiT9uzMB2s1F8a+U2wM4RrfG/VQnvpMnb0rjDKCdHPFSLu1ffhXcVfHzd
Bur+MCRB0eCghKKcmYVWHiD5FFkcbAvqDpMOjOHlN+J35D+dAS4eJMD9L5zkaltq
tNWzxJsZEz6zXNgO1Yx43Cqcygml43DpIxVfdbEtzhqgThpT7trkaA5wrlVNxFdc
2YjX5u6Oek7aKugmi86i2E7JGTB081kLCDlon531nZugocYK3jJ7QrZ35tOP/awo
qGt/l/nF6H23yhjhHou30p+EUnqpN7i7cO6d5bkT2NYFEJsyvWp4g/0Qg48qfapl
9KKB0fdXdxsndkUoDQiXCjc1alIxa+kKykEg1tehygCqOjsZIAY=
=onU4
-----END PGP SIGNATURE-----
