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

From: Matthias Andree <mandree_at_FreeBSD.org>
Date: Tue, 22 Apr 2025 19:34:30 UTC
Am 22.04.25 um 20:40 schrieb John Baldwin:
> 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).  So, no, this doesn't change
> anything in libc++ itself.  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.
> 

Last time I looked, we couldn't mix things though. Case in point, 
graphics/rawtherapee.  Once you tell it to use GCC *and* libstdc++, due 
to its use of other C++ libraries, we break linking because the 
std::string implementations between libstdc++ and libc++ are not 
interchangeable.  For an isolated application that just uses standard 
library features, we're good, but once other C++ binary libraries (.so 
files) come into play, we're stuck.

And once a compiler uses builtins that the oldest supported libc++ - 
that of FreeBSD 13.4 - doesn't support, we limit what the application 
can do.  This prevented specifically updating the default ports GCC and 
it's stuck until 13.4 will have gone out of support.

-- 
Matthias Andree
FreeBSD ports committer