[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-testers] autoconf-2.72e released [release candidate]
From: |
Frederic Berat |
Subject: |
Re: [platform-testers] autoconf-2.72e released [release candidate] |
Date: |
Wed, 20 Dec 2023 20:03:50 +0100 |
On Wed, Dec 20, 2023 at 5:17 PM Zack Weinberg <zack@owlfolio.org> 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@panix.com>
>
> 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@panix.com
>
> 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-----
>
>
- autoconf-2.72e released [release candidate], Zack Weinberg, 2023/12/20
- Re: [platform-testers] autoconf-2.72e released [release candidate],
Frederic Berat <=
- Re: [platform-testers] autoconf-2.72e released [release candidate], Zack Weinberg, 2023/12/20
- Re: [platform-testers] autoconf-2.72e released [release candidate], Frederic Berat, 2023/12/21
- Re: [platform-testers] autoconf-2.72e released [release candidate], Zack Weinberg, 2023/12/21
- AT_MTIME_DELAY not working? (was: Re: [platform-testers] autoconf-2.72e released [release candidate]), Jacob Bachmeyer, 2023/12/21
- Re: AT_MTIME_DELAY not working? (was: Re: [platform-testers] autoconf-2.72e released [release candidate]), Zack Weinberg, 2023/12/22
- Re: AT_MTIME_DELAY not working?, Nick Bowler, 2023/12/22
- Re: AT_MTIME_DELAY not working?, Zack Weinberg, 2023/12/22
Re: autoconf-2.72e released [release candidate], Alan Coopersmith, 2023/12/21