about the libc++ conversion

Chris Jones jonesc at hep.phy.cam.ac.uk
Fri Jun 2 13:56:39 UTC 2017


The fact that in some cases mixing the two C++ runtimes does not lead to 
obvious issues is *not* a general proof that there is not a problem in 
doing this. The issues generally occur when the application passing 
information between the two runtimes, if in those two runtimes the same 
type of object (std::string is a prime example) does not have the same 

So all you have proved is, in your examples, you do not trip over this. 
You have not proved in gerenal it is a safe thing to do.


On 02/06/17 12:10, René J.V. Bertin wrote:
> Hi,
> This is mostly out of curiosity and for personal education.
> I've been tinkering a bit with the libcxx port, upgrading it to 4.0.0 and getting it to build on Linux to have a reproducable way of installing libc++ there.
> I went with the standard build that uses libstdc++ instead of libc++abi but from what I saw it can also be built to use a (static) copy of libsupc++ (the true equivalent of libc++abi from what I understand).
> I then built a Qt5 application using clang -stdlib=libc++ knowing that Qt5 and everything else is built with gcc6 and against libstc++, expecting to see exactly what can go wrong when you mix those 2 runtime libraries.
> The answer is zip, nada, there's nothing indicating I'm using 2 different C++ runtimes. Maybe the application actually doesn't use libc++ at all, but it does beg the question if this couldn't have been an approach to simplify the libc++ conversion on older OS X versions.
> Note that I'm doing something comparable (but even wilder) with my libc++ conversion of GCC; the system libc++ on OS X 10.9 lacks at least 1 delete function, and thus I pull in libsupc++ when linking with my libc++-enabled g++-mp-7 . This has worked fine until now with everything I've thrown at it.
> R.

More information about the macports-dev mailing list