about the libc++ conversion

[Chris Jones]

Hi,

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 
implementation.

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.

Chris

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.
>