On Apr 22, 2025, at 12:34, Matthias Andree <mand...@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 <j...@freebsd.org> >>>> AuthorDate: 2025-04-11 13:53:50 +0000 >>>> Commit: John Baldwin <j...@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++ . However, that does not mean that various ports are set up to allow a required set of them (that are g++ based) for a specific purpose all to build with libc++ instead of libstdc++ . I'm not aware of any infrastructure set up for a global "use libc++ when using lang/gcc*" when building packages (or ports). === Mark Millard marklmi at yahoo.com
