src: Use gnu++17 as the default C++ standard

[jhb]

Summary

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.

[jhb]

This passes most of make tinderbox (it is finishing the last few arches for me still). It will need an exp-run as well.

[asomers]

This LGTM. C++20 would be nicer, because it would simplify one thing in the fusefs tests, but that would require a whole new tinderbox run.

[dim]

Yeah, go for it. :)

[jhb]

My gut feeling is that C++ 20 is too new still, but we may want to more clearly define what "too new" means. GDB's standard is something like "what is the max C++ version supported by the newest compiler that can be installed on the oldest supported Linux LTS" or some such, and GDB is currently at C++17.

share/mk/bsd.sys.mk

25

Possibly worth noting: I think both GCC and clang actually default to gnu++17, but I'm not aware of any GNU-isms that we depend on (we have a small C++ corpus in base anyway), and I think it might be beneficial if we can stick to "standard" C++ in base.

[emaste]

My gut feeling is that C++ 20 is too new still, but we may want to more clearly define what "too new" means.

Probably, yeah. I'd be fine with "some tests aren't available if your compiler doesn't support C++20."

[jhb]

exp-run found a few ports: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285141

[jhb]

So of the broken ports, 3 of them were due to code assuming GNU C++ instead of standard C++ (e.g. #ifdef unix instead of #ifdef __unix__ or #ifdef i386 instead of #ifdef __i386__). One was manually frobbing CXXFLAGS instead of using USE_CXXSTD, and the ports framework was not handling bsd.*.mk correctly for USE_CSTD and USE_CXXSTD. The framework was just adjusting CFLAGS and CXXFLAGS but then bsd.sys.mk would append to those with the default overriding the setting.

[jhb]

For the ports assuming GNU C++, I think it's easier if we just let the default be "gnu++17" instead of strict "c++17". This matches our default CSTD and what the out-of-the-box standard GCC and clang use and will be simpler even if base builds fine with a stricter "c++17"

[imp]

In D49223#1130005, @jhb wrote:

For the ports assuming GNU C++, I think it's easier if we just let the default be "gnu++17" instead of strict "c++17". This matches our default CSTD and what the out-of-the-box standard GCC and clang use and will be simpler even if base builds fine with a stricter "c++17"

Gnuc++17 as a default likely is fine

[jhb]

Use gnu++17

[dim]

Yes, this is fine too. At some point both gcc and clang switched to gnu++17 by default, but it's better to be explicit.