Re: AX_CXX_COMPILE_STDCXX fails to select default C++ standard automatically

Exactly.

29.03.2026 22:16, Sam James пишет:
> 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