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

Hi there.

Ewwwwwwww, you're was right. It hit me between the eyes - my bad ((((( 
My wrong logic here.

Must be:

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])
   fi
   if test "$HAVE_CXX17" = "0"; then
     AX_CXX_COMPILE_STDCXX(14, [noext], [optional])
   fi
   if test "$HAVE_CXX14" = "0"; then
     AX_CXX_COMPILE_STDCXX(11, [noext], [mandatory])
   fi
fi

Now all works correctly with 2.73.

Sorry for troubles.

WBR, Yuri.

29.03.2026 22:17, Yuri пишет:
> 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