about the libc++ conversion
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:
> 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.
More information about the macports-dev