Re: _AC_PROG_CXX_CXX11 is broken in C++20

Sam James <[email protected]> Wed, 21 Jan 2026 05:32:19 +0000

Newsgroups	gmane.comp.sysutils.autoconf.bugs,gmane.comp.lib.gnulib.bugs
Organization	Gentoo
Message-ID	<[email protected]>

Jonathan Wakely <[email protected]> writes:

> On Tue, 20 Jan 2026 at 09:20, Jonathan Wakely <[email protected]> wrote:
>>
>> On Mon, 19 Jan 2026 at 19:16, Zack Weinberg <[email protected]> wrote:
>> >
>> > On Thu, Jan 15, 2026, at 6:03 PM, Paul Eggert wrote:
>> > > On 1/14/26 04:07, Jonathan Wakely wrote:
>> > >> Would it make sense to do an Autoconf 2.72.1 release which is
>> > >> identical to 2.72 except it fixes this serious incompatibility with
>> > >> GCC 16?
>> > >
>> > > Easier would be to simply release what we've got.
>> >
>> > I was thinking the same thing.  We have a whole bunch of relatively low-
>> > risk patches stacked up in git, might as well call them 2.73.
>> >
>> > I'd like to see some broad testing first, though.  What if I put out an
>> > alpha release sometime this week and distribution maintainers do some
>> > mass rebuilds with it?  Also, does anyone know of any high-importance
>> > patches waiting for review, or other high-importance bugs that should be
>> > addressed ASAP?
>>
>> A 2.73 release seems fine, but a 2.72.1 would be zero risk and has
>> already been tested. That would be easier for distros to switch to in
>> stable releases. If there isn't an official 2.72.1 then distros are
>> just going to patch 2.72 locally (we've already done this in Fedora,
>> as have Gentoo) and now we have at least three slightly different
>> versions of 2.72 in circulation, generating slightly different
>> 'configure' files, but claiming to be
>
> (sorry, hit send too soon!)
>
> ... claiming to be 2.72

Yes, the unfortunate thing is that 2.73 will never be backported in a
distro and upstreams often cling to old autoconf (partly for AC_PREREQ
reasons).

But I understand Paul's point about the minimum cost for a release too.

signature.asc (application/pgp-signature, 418 B)