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
Description: PGP signature
