Am 22.04.25 um 22:46 schrieb Mark Millard:
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++ .
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
