Yuri <[email protected]> writes: > Sorry, I'll try to explain. Before version 2.72, the dnl code:
Do you mean 'before 2.73', given you said 2.72 is OK below? > > dnl If the user did not specify a C++ version. > if test -z `echo "$PRESET_CXXFLAGS" | $GREP -o -E "\\-std="`; then > dnl Set highest possible C++ support > AX_CXX_COMPILE_STDCXX(20, [noext], [optional]) > if test "$HAVE_CXX20" = "0"; then > AX_CXX_COMPILE_STDCXX(17, [noext], [optional]) > elif test "$HAVE_CXX17" = "0"; then > AX_CXX_COMPILE_STDCXX(14, [noext], [optional]) > elif test "$HAVE_CXX14" = "0"; then > AX_CXX_COMPILE_STDCXX(11, [noext], [mandatory]) > fi > fi > > in configure.ac worked perfectly. Here, a choice is made between four > alternatives, with the -std flag set if necessary. > After upgrading to 2.73, the check broke for outdated but still-usable > versions of GCC (in particular). The result is > that the compiler runs without the flag, which means for gcc 5.5, the C++98 > standard is selected. This breaks the build > and requires determining the compiler version (which requires more complex > code, similar to OpenSSH) and the standard's > flag table. The relevant chances in 2.73 are: commit 056518b94ecd487bcbefdb69046b3f52c4168222 Author: Paul Eggert <[email protected]> AuthorDate: Tue May 28 09:31:11 2024 -0700 Commit: Paul Eggert <[email protected]> CommitDate: Tue May 28 09:44:25 2024 -0700 AC_PROG_CXX no longer adjusts C++ language version commit f6522328c71a62e3d182def319167ac15c8feaa5 Author: Paul Eggert <[email protected]> AuthorDate: Sun May 26 09:20:56 2024 -0700 Commit: Paul Eggert <[email protected]> CommitDate: Sun May 26 09:24:02 2024 -0700 AC_PROG_CXX now tries C++23, C++20, C++17, C++14 That top (later) commit came out of a similar discussion to the one we're having here. > > Please note that all previous versions (up to and including 2.72) behave > completely correctly. If a user wants to enforce > a known version of the standard, they specify the option during > configuration. Changing behavior without warning means > breaking the contract and requires significant code changes, possibly > breaking backward compatibility. Given that I can't > exclude a specific version of autoconf without serious reconfiguration > tricks, my only option is to disable any use of > versions newer than 2.72 or write my own compiler check macro and set the > flag. My point is that sometimes the minimum > level of full standard support requires setting the flag. The user may not be > aware of this, but the compiler developers > are aware, and there is a fairly reliable mechanism for detecting this flag. > Therefore, I don't understand the rationale > for breaking this behavior. It's still not completely clear to me how much of this is autoconf vs autoconf-archive given you've not shown an autoconf-only testcase, plus the versioning confusion I mention too. See https://marc.info/?l=autoconf&m=171691458821106&w=2 and https://marc.info/?l=autoconf&m=171692427327427&w=2. > > This is not about enforcing the latest standard, it’s about selecting the > highest fully supported standard automatically > when the user provides no flags. > How does autoconf figure out what the highest fully supported standard is, keeping in mind what I raised? > 29.03.2026 21:27, Sam James пишет: > > Tom Lane <[email protected]> writes: > > Yuri <[email protected]> writes: > > Expected behavior: > > > * |AX_CXX_COMPILE_STDCXX| should automatically detect and use the > highest supported standard if the user does not provide any flags. > > > Is "highest supported standard" really the right decision rule? > I would personally have expected "use the compiler's default", > if no other guide is available. > > > It's actually unsafe as well, because a compiler may support newer > -std=XYZ but it could be experimental at least wrt ABI. GCC does that > and I think Clang does as well (at least for libstdc++, it has no > choice). > > So, say, -std=c++26 being supported by the compiler doesn't mean it should > be used. > > [...] > > > sam
signature.asc
Description: PGP signature
