Opened 7 months ago

Closed 3 months ago

Last modified 3 months ago

#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 3 months ago by cjones051073 (Chris Jones)

Resolution: wontfix
Status: newclosed

This is intentional to avoid a runtime dependency on the full clang port.

comment:2 Changed 3 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.

Note: See TracTickets for help on using tickets.