get GCC to use libc++?

[RJVB (René Bertin)]

(I guess this is a request for an enhancement...)

In reaction to Marcus's new C++11 PG (which I think implements ​this idea) I wondered if it wouldn't be possible to create a modified GCC build that uses libc++ . In my experience on Linux GCC 6 still creates sometimes significantly faster code and the build speed gap has narrowed with every new clang release becoming slower and every new GCC release becoming faster. So there could be a real benefit to using GCC for code that doesn't require any clang-specific features like blocks - meaning the vast majority of cross-platform software.

GCC can be made to use libc++ at runtime (​http://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc) so it should be possible to hardcode the paths/options provided in that example. Has this been tried before (I couldn't find any trace on google)?

[kencu (Ken)]

I would just reiterate that this whole line of work (monkeying with newer clangs to make them compatible with gcc4-ABI, and this suggestion above) are ONLY because we can't seem to come up with a consensus on setting up libc++ buildbots for <10.9.

IMHO, this is all more or less a big waste of time, sends us down the wrong path, and will in the end cause confusion.

Let's change the builtbots to libc++ (which certainly can be done) OR add libc / libstdc to the filenames (or some more difficult and unlikely metadata solution), and get everyone on board with libc++ (which I think we would all agree is the proper fix for this).

[RJVB (René Bertin)]

Can we please keep this ticket dedicated to using GCC with libc++, regardless of whether that library is a standard system library or not?

[RJVB (René Bertin)]

Getting GCC to use libc++ instead of libstdc++ is probably not so very difficult as just a matter of setting the LIBSTDCXX macro appropriately. That would be possible with a -DLIBSTDCXX=c++ compiler option if it weren't for the fact that we also may need to link to libc++abi.

Do we, in fact?

I'm building gcc6 now with a patch that should make it use -lc++ -lc++abi instead of -lstdc++.

For the headers it's a bit more complicated as their path isn't hardcoded in a way that can be patched easily, but generated dynamically. As a result, it'll be easier to replace the whole ${prefix}/include/gccN/c++ directory with a symlink to the corresponding clang/llvm/libc++ directory.

And those have to be from a port:clang-xy install; at least GCC6 won't work with the headers from Xcode for OS X 10.9 .

[neverpanic (Clemens Lang)]

​http://stackoverflow.com/questions/22228208/using-g-with-libc

[RJVB (René Bertin)]

Thanks, but I think I have something a little more elegant :)

Preliminary build tests succeed, as long as I don't allow the compiler to use AVX intrinsics. Apparently GCC uses a dialect or simply operations that the cctools as command doesn't grok (on 10.9.5).

The 10.9.5 system libc++ also appears to be missing the operator delete(void*, unsigned long) function which is used in an intermediate executable. When was that function added to libc++?

[RJVB (René Bertin)]

A small change to address build errors probably due to the order in which "system" C++ headers were included.

I seem to recall that gcc used to have spec files for its internal configuration details. This kind of tweak could possibly be handled completely via such a spec file, but nowadays they seem to be built in. Anyone here familiar with those files?

Edit : as a test I built port:kf5-kdevelop-clang-parser-devel (​https://github.com/RJVB/macstrop/tree/master/kf5/kdevelop5) with GCC 6; it builds and runs fine in the host app which is built with clang 3.9.0 .

Only disadvantage I've seen: GCC seems to generate AVX intrinsics that as from port:cctools doesn't grok, so I cannot let the compiler do AVX-based auto-vectorisation. It remains to be seen if that comes with a noticeable performance penalty outside of very specific benchmarks (probably not).

[mf2k (Frank Schima)]

A "request" ticket type is only for requesting a new port.

[RJVB (René Bertin)]

Improved version

• adds GCC's libsupc++ (static lib) which provides a number of symbols missing from older libc++ versions
• better mechanism through which libstdc++ is pulled in during the GCC build (it remains to be seen if it isn't better to deactivate libc++ entirely during GCC's own build)
• drops the symlinked llvm/c++ header directory and adds an env. variable to override the default, built-in llvm/c++ header directory
• new libcxx variant that sets the default llvm/c++ header dir to the one of the default system toolchain (not a good idea on 10.9)

[RJVB (René Bertin)]

(Annoying that I cannot change the ticket title)

This is a new version of the port:gcc6 patch which adds a related fix that makes the GCC compiler family (including gfortran) more usable by allowing them to target more recent CPUs than those supported by the as command in port:cctools.

This is done via a variant (default when using a +libcxx variant) that configures GCC to use the wrapper script from the proposed port:gccas. That turns the GCC compilers into a front-end for the LLVM assembler and linker.

[RJVB (René Bertin)]

Given the enthusiasm this stirs and the ongoing development I'm doing on the feature I invite interested users to follow the evolution via my git repo:

​https://github.com/RJVB/macstrop/tree/master/lang/gcc6 ​https://github.com/RJVB/macstrop/tree/master/devel/gccas