[MacPorts] #70341: g++ fails to compile when -libstd=libc++ is set

MacPorts noreply at macports.org
Mon Jul 8 19:02:49 UTC 2024


#70341: g++ fails to compile when -libstd=libc++ is set
--------------------------+--------------------
  Reporter:  mouse07410   |      Owner:  (none)
      Type:  defect       |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  gcc12 gcc13  |
--------------------------+--------------------

Comment (by cjones051073):

 So, here is the thing. libc++ support with GCC is, and always has been,
 somewhat experimental. Its a nice idea, and when I first added support it
 worked OK, for some cases, but even then you could not compile every you
 could with GCC+stdlibc++ or clang+libc++, there where plenty of things
 which just did not work.

 Part of the problem is GCC expects the LLVM/clang headers to use when
 targeting libc++ to be externally supplied to the build, GCC does not ship
 a compatible set itself. The question then of course is which to use, and
 here it gets even murkier as GCC has varying support for different
 versions. Xcode does not (from memory) supply anything usable so we have
 to rely on one of our own clang ports.

 This is where the sub-ports `gccN-libcxx` come in. These take a copy of
 the required headers, from a clang version, and these are then use during
 the GCC build.

 These sub-ports offer various possible clang versions to use, with one
 picked as the default. e.g.

 {{{
 Larissa ~/Projects/MacPorts/ports > port info gcc13-libcxx
 gcc13-libcxx @13.3.0_1 (lang)
 Variants:             clang11, clang12, clang13, clang14, clang15,
 [+]clang16, clang17, clang18

 Description:          libc++ header implementation to be used by gcc13
 Homepage:             https://llvm.org/

 Build Dependencies:   clang-16
 Platforms:            any
 License:              NCSA
 Maintainers:          none

 }}}

 now, the best I can get is with gcc14 (I have built from source so
 currently by-passing the issues in https://trac.macports.org/ticket/70331)
 and when I have upped the clang version to 17. Even then I get

 {{{
 Larissa ~/cernbox/MacPorts/simple > g++-mp-14 -stdlib=libc++ ./test.cpp
 In file included from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/new:99,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/__memory/construct_at.h:23,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/__memory/allocator_traits.h:14,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/__memory/allocation_guard.h:15,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/__memory/shared_ptr.h:22,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/__locale:15,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/ios:222,
                  from
 /opt/local/libexec/gcc14/libc++/include/c++/v1/iostream:43,
                  from ./test.cpp:1:
 /opt/local/libexec/gcc14/libc++/include/c++/v1/cstdlib:144:9: error:
 'at_quick_exit' has not been declared in '::'
   144 | using ::at_quick_exit _LIBCPP_USING_IF_EXISTS;
       |         ^~~~~~~~~~~~~
 /opt/local/libexec/gcc14/libc++/include/c++/v1/cstdlib:145:9: error:
 'quick_exit' has not been declared in '::'
   145 | using ::quick_exit _LIBCPP_USING_IF_EXISTS;
       |         ^~~~~~~~~~
 Larissa ~/cernbox/MacPorts/simple >
 }}}

 which in itself is yet another issue we have been seeing in a few places
 recently.

 So Mouse, by all means play with this. Try out different clang versions to
 use as the header source. But, in the end, this is experimental 'you get
 what you pay for' level stuff at the moment I am afraid.

-- 
Ticket URL: <https://trac.macports.org/ticket/70341#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list