On Wed, Dec 20, 2023 at 5:17 PM Zack Weinberg <zack@xxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > autoconf-2.72e is now available. This is a *release candidate* > for autoconf 2.72 final. Please test it as thoroughly as possible. > Testing in Windows- and Darwin-based environments would be > particularly helpful. Testing your own project’s configure.ac with > the new autoconf is also particularly helpful. > > Unless there are show-stopper bugs, I intend to make the final > release in 48 hours, on 2023 December 22. > > There have been 19 commits by 4 people in the 20 days since 2.72d. > See the NEWS below for a brief summary. > > Thanks to everyone who has contributed! > The following people contributed changes to this release: > > Bruno Haible (1) > Detlef Riekenberg (1) > Paul Eggert (5) > Zack Weinberg (12) > > 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.72e > or run this command from a git-cloned autoconf directory: > git shortlog v2.72e..v2.72e > > Here are the compressed sources: > https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.gz (2.1MB) > https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.xz (1.4MB) > I admit I usually don't build the package for i386 since autoconf isn't arch dependent, but I did it this time and there are few test failures: 420: AC_SYS_LARGEFILE FAILED (semantics.at:908) 421: AC_SYS_YEAR2038 FAILED (semantics.at:917) 422: AC_SYS_YEAR2038_RECOMMENDED FAILED (semantics.at:926) Tested on Fedora rawhide i386. I let you judge if that can be categorized as a blocker though. > Here are the GPG detached signatures: > https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.gz.sig > https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.xz.sig > > Use a mirror for higher download bandwidth: > https://www.gnu.org/order/ftp.html > > Here are the SHA1 and SHA256 checksums: > > 8352c1ebf9e1f0c2f62cc31426ea6da02475195d autoconf-2.72e.tar.gz > 80eNO1l9UfXWFZb7L29quknN2XS0sF/wusV/VrXP2zk= autoconf-2.72e.tar.gz > f85f9f1044bfc5fadd550c2c2fea15a541e5c02e autoconf-2.72e.tar.xz > fNwkseg6uiFz0+LdAoPgCpMWtKomDlk5I8frrgIX2co= autoconf-2.72e.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.72e.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.72e.tar.gz.sig > > This release was bootstrapped with the following tools: > Automake 1.16.5 > > NEWS since 2.71: > > * Noteworthy changes in release 2.72e (2023-12-20) [release candidate] > > ** Further improvements to subsecond timestamp handling > > Two subtle bugs were fixed. Also, ‘autom4te --version’ now reports > whether autom4te is capable of reading subsecond timestamps from > the file system, enabling other programs (notably Automake) to > adjust their own behavior appropriately. > > There may still be problems with subsecond timestamps (see below). > Because timestamp comparison is only used for autom4te’s cache, > the only practical effect of these problems is to cause spurious > failures in Autoconf and Automake’s test suites, in tests of the > cache itself. > > ** Significant bug fixes > > *** autom4te works with perl 5.6.x again > *** BusyBox ‘mkdir’ is correctly identified > *** AC_FUNC_MMAP successfully detects mmap on CheriBSD > *** Better error message for calling m4_warn() with a bad first argument > > ** 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. > > See <https://savannah.gnu.org/support/index.php?110983> for details > and a workaround. > > *** “autoconf: forbidden tokens, basic�€? testsuite failure > > We believe this is another subtle bug in autom4te’s handling of > timestamps that are very close together. It only happens on some > operating systems and/or some file systems. It can safely be ignored. > See <https://savannah.gnu.org/support/index.php?110986> for more detail. > > *** “Substitute and define special characters�€? testsuite failure > > We believe this to be a bug in some versions of NetBSD /bin/sh. > If you see this failure on any system besides *-unknown-netbsd9*, > please post a comment on < > https://savannah.gnu.org/support/index.php?110985> > and attach a tarball of the failed test’s scratch directory > (${builddir}/tests/testsuite.dir/270 in version 2.72; the number > may change in the future as tests are added or removed). > > * Noteworthy changes in release 2.72d (2023-11-30) [beta] > > ** 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 blacklist of OSes with > known, severe bugs in getgroups. It can be overridden using > config.site. If you encounter a mistake in this blacklist > 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 gotten around to taking 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 > > *** Autoconf caches now use finer-grained timestamps. > > Autoconf now uses floating-point numbers rather than integers to > represent cache file timestamps, thus avoiding some problems where > automake incorrectly decides not to regenerate stale caches. > > *** AC_HEADER_STDBOOL, AC_CHECK_HEADER_STDBOOL are obsolescent and less > picky. > > These macros are now obsolescent, as 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. > > * Releases 2.72a,b,c were snapshots that did not get their own > NEWS entries. > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEgvhU885zF0uLYxdAkfzDK2dpqmQFAmWDExQACgkQkfzDK2dp > qmQvwg/9FzD28Vw6KipMfe6Zh6NPHXGvfXPOkMst7yI2PpRFNtMN/5QYinoey6PW > 2GgC/rS/10h24V6XgfVjDuUDX2SMTGUV1/V0GAL3kEWzY+ohaTX0AWpuq6JzV2/S > fvWxG1I6kshYUVOKGAXh2LdmICx4EAHOig50Copd+dQsbD3D3zta7Bx10Ib6sceb > Fv6lpbT3kVpvEBYInWwIc6QzPZolx+HYGW+jU4UqDefgmkyrPWdh+vLqqhANiftA > TpbhQ750yWXJmkkd7pGkve67mYLAs+vTe5Wk5utYGwFJH42x3siE2zRoC89cHGFv > lbDynXUR83d3aC40KXbESiMyD/PlEbhtvCPHVclrFAi09LkviI0Xy+nckNM5WqPA > S4trHZc1hjLnkN5ce6jU1qMfsLEDqZ3l/mv+57ak/I3H0KK5JJF6rzut5nkC+t1N > pHOLKO8Q9jgLPxbVrGA/68p+y7kBy9FsuFR4i9VoUDHJN3qef2Vl5dmWfK5Rwr0g > dQCPSfDoGO2wXL+tydn7LM3e5q7GreT1QSyeZCHyYtCSPmEQjbZeoUF5SliXjJ4k > HrfVolnIpmpzl8It/7lnM45W/Li7L7wvp2GQHuNNA+/5LXun9Wn2Gs+r2F3LAVle > y9WExww1pp0/cSBvwIQBnqH9ETiYoqqL7H5QDt1yQhCG06PC5hY= > =6/0p > -----END PGP SIGNATURE----- > >
