Re: _AC_PROG_CXX_CXX11 is broken in C++20

Sam James <[email protected]> Thu, 15 Jan 2026 20:48:31 +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, 6 Jan 2026 at 23:38, Paul Eggert wrote:
>>
>> On 1/6/26 14:16, Bruno Haible wrote:
>> >    - AC_PROG_CXX        should not change the CXX variable.
>> >    - AC_PROG_CXX([98])  should not change the CXX variable.
>> >    - AC_PROG_CXX([11])  should try the -std=gnu++11 option and, if it is needed
>> >                         and it works, add it to the CXX variable.
>> >    - AC_PROG_CXX([17])  should try the -std=gnu++17 option and, if it is needed
>> >                         and it works, add it to the CXX variable.
>> >    - AC_PROG_CXX([20])  should try the -std=gnu++20 option and, if it is needed
>> >                         and it works, add it to the CXX variable.
>> >    - AC_PROG_CXX([23])  should try the -std=gnu++23 option and, if it is needed
>> >                         and it works, add it to the CXX variable.
>> >    - AC_PROG_CXX([26])  should try the -std=gnu++26 option and, if it is needed
>> >                         and it works, add it to the CXX variable.
>>
>> This sounds like a good improvement to Autoconf. cc'ing bug-autoconf so
>> that it gets recorded there. For Autoconf readers: the thread starts here:
>>
>> https://lists.gnu.org/r/bug-gnulib/2026-01/msg00030.html
>
>
> 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?
>

Yes, if at all possible, this would be a big help.

> In Fedora we have a patched Autoconf 2.72 but that means if somebody
> runs autoconf on Fedora they get a different configure file than
> anybody who runs the official autoconf-2.72, and if other maintainers
> of a package rerun autoconf on a different distro, they'll reintroduce
> the bug into their configure scripts. If they don't test with GCC 16
> yet (which won't even be released for another few months, and won't be
> evenly distributed until even later) then they won't know they have a
> broken configure script, until users try to build the released package
> using GCC 16.

Indeed it'll be a whole thing with trying to explain to upstreams why
their `make dist` tarball wasn't OK (using vanilla autoconf, either from
a distro that didn't patch autoconf or from the upstream tarball).

>
> An 2.72.1 release with no other changes except for fixing this bug
> would be a major benefit to the community. The sooner that 2.72.1
> could replace 2.72, the better. That will help to ensure that even if
> some packages have already been released with buggy configure scripts,
> users could rerun autoconf themselves to fix the configure scripts
> before running them.

Is there anything I can do to help make this happen?

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