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

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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=3D"`; then
>   dnl Set highest possible C++ support
>   AX_CXX_COMPILE_STDCXX(20, [noext], [optional])
>   if test "$HAVE_CXX20" =3D "0"; then
>     AX_CXX_COMPILE_STDCXX(17, [noext], [optional])
>   elif test "$HAVE_CXX17" =3D "0"; then
>     AX_CXX_COMPILE_STDCXX(14, [noext], [optional])
>   elif test "$HAVE_CXX14" =3D "0"; then
>     AX_CXX_COMPILE_STDCXX(11, [noext], [mandatory])
>   fi
> fi
>
> in configure.ac worked perfectly. Here, a choice is made between four alt=
ernatives, with the -std flag set if necessary.
> After upgrading to 2.73, the check broke for outdated but still-usable ve=
rsions 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 comple=
x 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 configura=
tion. Changing behavior without warning means
> breaking the contract and requires significant code changes, possibly bre=
aking backward compatibility. Given that I can't
> exclude a specific version of autoconf without serious reconfiguration tr=
icks, 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 no=
t be aware of this, but the compiler developers
> are aware, and there is a fairly reliable mechanism for detecting this fl=
ag. 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=3Dautoconf&m=3D171691458821106&w=3D2 and
https://marc.info/?l=3Dautoconf&m=3D171692427327427&w=3D2.

>
> This is not about enforcing the latest standard, it=E2=80=99s about selec=
ting 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 =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>
>  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=3DXYZ 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=3Dc++26 being supported by the compiler doesn't mean it sho=
uld
> be used.
>
>  [...]
>
>
> sam

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEBBAEWCgCpFiEEJaa7iN2bdkxrVUHCc4QJ9SDfkZAFAmnJXoMbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyNUE2QkI4OEREOUI3NjRDNkI1NTQx
QzI3Mzg0MDlGNTIwREY5MTkwDxxzYW1AZ2VudG9vLm9yZwAKCRBzhAn1IN+RkPwJ
AQC6pjGg6DqQXfWTFNsWfKEw27YbiGZc/Me++fDbaxyTEgEAqoeLuQ2yOUPLARjI
aruOBFYtRDlLa+GQrz09GS9VaA0=
=c6Ei
-----END PGP SIGNATURE-----
--=-=-=--