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?

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.

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.


Reply via email to