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

Am 22.04.25 um 22:46 schrieb Mark Millard:
> On Apr 22, 2025, at 12:34, Matthias Andree <mandree@FreeBSD.org> wrote:
> 
>> 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.
> 
> One thing that modern enough lang/gcc* do allow is use of
> -stdlib=libc++ instead of -stdlib=libstdc++ .

That is the necessary condition for using GCC for C++ on FreeBSD as soon 
as any other C++ library comes into play.

> I'm not aware of any infrastructure set up for a global
> "use libc++ when using lang/gcc*" when building packages
> (or ports).

Neither am I. 
https://cgit.freebsd.org/ports/tree/graphics/rawtherapee/Makefile is 
full of (halfway documented) workarounds.  This is mostly to deter 
fellow ports furies from "cleaning up" and breaking the port.

-- 
Matthias Andree
FreeBSD ports committer