RE: git: 6527682ab705 - main - src: Use gnu++17 as the default C++ standard
Date: Fri, 11 Apr 2025 17:14:16 UTC
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