On Tue, 6 Jan 2026 at 22:19, Bruno Haible <[email protected]> wrote: > > Paul Eggert wrote: > > On 2026-01-05 10:12, Jonathan Wakely wrote: > > > - char const *utf8 = u8"UTF-8 string \u2500"; > > > + auto const *utf8 = u8"UTF-8 string \u2500"; > > > > Thanks, I installed that into Gnulib for now > > The change looks good: it tests for the presence of two features of C++11 > [1][2]. > > > though I'm still > > interested in the more-ambitious approach (taken by bleeding-edge > > Autoconf) of not fiddling with C++ versions here. > > https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=056518b94ecd487bcbefdb69046b3f52c4168222 > > I understand the motivation of this change: > The old AC_PROG_CXX code was made for the situation (predominant from > ca. 2000 to 2015) where the C++ standard had evolved and the compilers > supported the new standard when the appropriate -std=... option was given, > but the compiler's default had not been bumped for a long time. > Since ca. 2020, the compilers not only support the new standards, but > also do so by default (despite the occasional backward-incompatibilities > between the C++ standards versions). The patch mentioned above terminates > a catch-up game between the C++ standards and the Autoconf versions. > > BUT in doing so, it makes it harder for the user / distro to build a > package: The user now needs to try e.g. -std=gnu++23 or -std=gnu++26 > depending on the package, and see which of them produces the fewest > compilation errors. This is against the principle of Autoconf. > > The principle of Autoconf is that the package's author *declares* the > requirements, and Autoconf arranges for setting CXX and CXXFLAGS so that > these requirements are met.
Agreed. Declaring the package's *actual* requirement (e.g. C++17) would be better than just saying the package needs "C++" and then autoconf (or gnulib) trying to guess at an appropriate -std option. > > In this case, it means the package's author should declare the C++ standard > that the package requires, and if that is new enough, Autoconf should > add -std=gnu++23 or -std=gnu++26 as needed. For instance, assume we change > AC_PROG_CXX so that it takes an optional standard version: > - 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 will make it unnecessary for the user / distro to try different CXX > values (CXX="g++", CXX="g++ -std=gnu++23", CXX="g++ -std=gnu++26"). > And, as far as I can see, it is future-proof in the sense that it will not > misbehave when the same package is built 5 or 10 years from now, with GCC 20 > or GCC 25 — except for the occasional backward-incompatibilities that the > C++ standards committee tries to avoid. Assuming that a package correctly uses AC_PROG_CXX([17]) when it directly or indirectly (via some 3rd party lib) requires C++17, that would have avoided the bug we encountered with GCC 16 in Fedora. Autoconf would have tested to see whether C++17 snippets compiled with $CXX unchanged, and if not (because the snippets included the 'char const *s = u8"string";' code which isn't valid with GCC 16's default options) would have added -std=gnu++17, which would have worked. It would not have downgraded from the default -std=gnu++20 all the way to -std=gnu++11, just to the version that the package declared as a requirement, -std=gnu++17.
