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
