bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

autoconf-2.72e released [release candidate]


From: Zack Weinberg
Subject: autoconf-2.72e released [release candidate]
Date: Wed, 20 Dec 2023 11:16:21 -0500

-----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)

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-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]