[MacPorts] #69446: gcc13-libcxx cumbersomeness
MacPorts
noreply at macports.org
Sat Jul 6 16:01:48 UTC 2024
#69446: gcc13-libcxx cumbersomeness
--------------------------+--------------------
Reporter: RJVB | Owner: (none)
Type: enhancement | Status: closed
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: wontfix | Keywords:
Port: gcc13 |
--------------------------+--------------------
Comment (by RJVB):
What full clang port? The old `port:libcxx` installs a standalone build of
libc++, the other libcxx port copies everything from a designated clang
install (which could/should be the bootstrapping approach IMHO).
Note that GCC already has a runtime dependency on a clang port via
port:cctools (clang is used as the "backend" for the assembler invoked by
GCC).
AFAICT ports built with G++ using libc++ as I suggest do not inherit a
runtime dependency on a clang port.
> (I have yet to check if it also makes libc++ the default on new-enough
OS X.)
It doesn't. In fact, the upstream patch does not do the same thing as the
old "manual" recipes for using libc++ with GCC that can still be found
online. Using those recipes gives way less build failures than the
upstream `-stdlib=libc++` implementation (because the libc++ headers get
to see the proper, = non-GNU versions of certain headers like `cdefs`).
I have a patched GCC12 that uses libc++ as the default (on 10.9+) and
defines the header search patch like the manual recipe would do (which is
the same approach used by the legacysupport PG to build against
port:libcxx). That custom GCC12 builds almost everything that doesn't
include Apple-style ObjC. It will even build libc++ itself, IIRC. FWIW, my
personal libc++ is at 13.0.1 and is built from source.
--
Ticket URL: <https://trac.macports.org/ticket/69446#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list