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.
--
Matthias Andree
FreeBSD ports committer
