[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