[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