#69446 closed enhancement (wontfix)
gcc13-libcxx cumbersomeness
Reported by: | RJVB (René Bertin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | gcc13 |
Description
Checking in on port:GCC developments I am pleased to see that a patch very similar to the one I wrote to add -stdlib=
functionality to GCC7 made it into the offical sources. (I have yet to check if it also makes libc++ the default on new-enough OS X.)
I have to wonder though why there's such a cumbersome libc++ header file construct. Why make another copy of the headers from a derived clang compiler (it seems to me the reproducible-build principle is thrown overboard with the way that subport currently works) if there's already port:libcxx
? Why not simply point GCC (and its build process) to that directory so it will see any upgrades of that libc++ version as one would expect?
/methinks it should also be possible to configure GCC to use the system libc++ headers by default on new-enough OS versions - my old custom port:gcc7 found them with file dir [exec xcrun --find clang]]/../include/c++/v1
.
Change History (2)
comment:1 Changed 4 months ago by cjones051073 (Chris Jones)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 Changed 4 months ago by RJVB (René Bertin)
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.
This is intentional to avoid a runtime dependency on the full clang port.