Re: git: 6527682ab705 - main - src: Use gnu++17 as the default C++ standard
- In reply to: John Baldwin : "Re: git: 6527682ab705 - main - src: Use gnu++17 as the default C++ standard"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 23 Apr 2025 00:37:47 UTC
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