Chris Jones wrote:
> type of object (std::string is a prime example) does not have the same
> implementation.
Do we have known examples that trigger the issue reliably?
As to the linker raising errors thanks to the use of different namespaces:
> However, if I read what's said about this on Linux forums I get the
> impression
> that the linker should or might raise errors because of the use of different
> namespaces.
That's right. I've seen errors that look like this, with this std::__1 business:
Undefined symbols for architecture
Chris Jones wrote:
> 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.
Not claiming to either, and I have tried Qt code above all. While usually
highly
complex I don't think it uses many STL or std classes.
> simplify the libc++ conversion on older OS X versions
I'm working on something related.
It turns out that Clang-3.8 / llvm 3.8 builds without too much trouble on 10.5
PPC, using gcc6 to build it (see my trac tickets if you would like to see how
to do that).
It can then build quite complex
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
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
