RE: git: 6527682ab705 - main - src: Use gnu++17 as the default C++ standard

John Baldwin <jhb_at_FreeBSD.org> wrote on
Date: Fri, 11 Apr 2025 13:54:30 UTC :

> The branch main has been updated by jhb:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=6527682ab7058e5023a2a6dea01d51c15dca701f
> 
> commit 6527682ab7058e5023a2a6dea01d51c15dca701f
> Author: John Baldwin <jhb@FreeBSD.org>
> AuthorDate: 2025-04-11 13:53:50 +0000
> Commit: John Baldwin <jhb@FreeBSD.org>
> CommitDate: 2025-04-11 13:53:50 +0000
> 
> src: Use gnu++17 as the default C++ standard
> 
> Previously the compiler's default C++ standard was used unlike C where
> bsd.sys.mk explicitly sets a default language version. Setting an
> explicit default version will give a more uniform experience across
> different compilers and compiler versions.
> 
> gnu++17 was chosen to match the default C standard. It is well
> supported by a wide range of clang (5+) and GCC (9+) versions.
> 
> gnu++17 is also the default C++ standard in recent versions of clang
> (16+) and GCC (11+). As a result, many of the explicit CXXSTD
> settings in Makefiles had the effect of lowering the C++ standard
> instead of raising it as was originally intended and are removed.
> 
> Note that the remaining explicit CXXSTD settings for atf and liblutok
> explicitly lower the standard to C++11 due to use of the deprecated
> auto_ptr<> template which is removed in later versions.
> 
> Reviewed by: imp, asomers, dim, emaste
> Differential Revision: https://reviews.freebsd.org/D49223

[The note below is just a thought prompted by this. It applies
to the prior context as well.]

As I understand many C++ ports use the system c++ toolchain
and libc++ to build and operate --and there is only one libc++
available in some respects. If that is the case
. . .

This ends ends up controlling the C++ library's features for
any libc++ library material used via any of:

/lib/libc++.so.1
/usr/lib/debug/lib/libc++.so.1.debug
/usr/lib/debug/usr/lib32/libc++.so.1.debug
/usr/lib/libc++.a
/usr/lib/libc++.so
/usr/lib/libc++experimental.a
/usr/lib32/libc++.a
/usr/lib32/libc++.so
/usr/lib32/libc++.so.1
/usr/lib32/libc++experimental.a

as well. FreeBSD and its ports have no means of using an
alternate libc++ as stands, as far as I know. Nor does
FreeBSD or its ports support using (or building) a
libstdc++ via the system's c++ as an alternative,
as far as I know.

One has an alternative if use of a g++* and its libstdc++
is a viable option.

So this may have implications for ports dependent on more
modern C++ library features that want or need to not use
a g++* .

I'm unsure of what issues may occur with vintage
mismatches for the above vs. forms of explicit use of
alternate -std=c++?? in ports that are using the c++
library. The libc++ headers will track but need not be
a good match to the above list in some respects?

This also applies to use of a g++* with -stdlib=libc++
(which various modern lang/gcc* support using).

===
Mark Millard
marklmi at yahoo.com