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

On Apr 22, 2025, at 11:40, John Baldwin <jhb@freebsd.org> wrote:

> On 4/11/25 13:14, Mark Millard wrote:
>> 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:
> 
> No, it does not.  libc++ is mostly templates and uses many #ifdef's
> to provide support for multiple language standards.  For the actual
> symbols required at runtime, we build libc++ such that it includes
> all of them (in particular, we use a higher CXXSTD to build libc++
> itself and have for a long time).

Thanks for that note.

I had always implicitly assumed that the likes of:

/usr/src/lib/clang/llvm.build.mk:CXXSTD?=       c++17

was in control of that (presuming no explicit override
in my builds). I'm unaware of anything documenting that
FreeBSD's libc++ .a and .so are based on something that
produces what I now find has -std=c++23 in the relevant
*o.meta files in my builds, such as in the various:

/usr/obj/BUILDs/main-CA76-dbg-clang/usr/main-src/arm64.aarch64/lib/libc++/*o.meta

I had never thought to double check that.

I think that some reference to the difference probably
should be documented, even if it mostly points to where to
look in the source tree to see the libc++ default if one
has a reason to care about the detail. In my current
context:

# grep -r -B4 -A1 'CXXSTD.*=' /usr/src/lib/libc++/ | more
/usr/src/lib/libc++/Makefile-.if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} < 130000
/usr/src/lib/libc++/Makefile-# NOTE: gcc 12 cannot correctly compile all libc++'s C++23 code. To temporarily
/usr/src/lib/libc++/Makefile-# support gcc 12, compile libc++ in C++20 mode, but this will leave out any
/usr/src/lib/libc++/Makefile-# C++23 features.
/usr/src/lib/libc++/Makefile:CXXSTD?=   c++20
/usr/src/lib/libc++/Makefile-.else
/usr/src/lib/libc++/Makefile:CXXSTD?=   c++23
/usr/src/lib/libc++/Makefile-.endif

Part of the point of documenting such is to note
that the likes of:

/usr/src/lib/clang/llvm.build.mk:CXXSTD?=       c++17

does not, of itself, override what is in:

/usr/src/lib/libc++/Makefile

I'll note that there have been a time or two
when libc++ did not include everything and I
prompted for something to be enabled that was
from the C++ standard and the LLVM was
supporting it but FreeBSD was missing it. So
I was unsure of that aspect as well.

"Everything" also gets into if -fexperimental-library
should cause anything contribute to libc++'s .a and
.so files. (Hopefully such is all header-only material.)
LLVM has even finished something but forgotten to
remove needing the -fexperimental-library enablement.
LLVM19 and jthread is an example. (LLVM20 finally
removes the need for -fexperimental-library use.)

I'm not claiming that -fexperimental-library
would be a good idea if any of it would
contribute to the .a and..or .so . But I know
that there are ports dependent on partial
implementations that -fexperimental-library
provides (if libc++ is to be used).

> So, no, this doesn't change
> anything in libc++ itself.

Understood: LIBCXX_ABI_VERSION based for
compatibility, avoiding LIBCXX_ABI_UNSTABLE
use.

> It merely changes the default C++
> environment when using bsd.*.mk.
> 
> The same is true of libstdc++ use by GCC.  It also supports the
> full range of C++ versions in the dynamic library and does not
> require separate builds for different C++ versions.

Seems to be:

GCC 3.4.0: libstdc++.so.6.0.0 and later so
far (ignoring the GCC 4.2.1: libstdc++.so.6.0.9
temporary mistake).

Thanks again,
Mark

===
Mark Millard
marklmi at yahoo.com