Just to be clear, You're attempting to build GCC 6.3 using Clang, and
you've hacked up the GCC build so that it always uses libc++ instead of
- I use clang for the initial bootstrap build (which is perfectly possible and nothing new), afterwards GCC builds itself. Multiple times.
- yes, I have a hack that causes the resulting compiler to use the c++ headers from clang, and libc++
- the hack is supposed to evolve into support for a `-stdlib` feature like clang has
Why are you forcing GCC to build against libc++ in the first place? What's
the benefit? Doesn't the build default to bootstrapping and using a
GCC itself is built against its usual static copy of libstdc++ and family (in the end that works out more reliably).
The benefit of my approach is simple and sufficiently obvious that the GCC team will consider the change once implemented properly. It's the only way G++ can be used on systems that use libc++ as the system C++ runtime without taking extreme precautions. It's not impossible to run binaries that use the libstdc++ runtime on Mac, but in practice they should not use any system SDKs that are written in C++, to avoid passing objects between libc++ and libstdc++.
AFAIK the GCC build doesn't use Boost, so IDK how Boost is getting into the
No, it doesn't. I ran into an issue building software using boost, and boost itself, when using the "libc++ enabled g++".
I've had the time to look into this further since asking here, and discovered that Boost has a number of places where it assumes that libc++ is used only together with clang. When I patched those the issues went away, at least on OS X 10.9 .
I would assume the issue *would* be present in the OS X's system libc++
installation, (assuming the system installation hasn't been updated to
include the fix, which it likely hasn't)
No, I haven't updated the system libc++. I have a more recent libc++ installed to the side (from the MacPorts package) which I insert into applications I run from a shell, but that doesn't help with anything that sneaks in at link time (or is run via the Finder).
But if I understand correctly the issue is relatively recent, and should thus not yet be present in installations that are now several years old, correct?