[cfe-dev] Current state of libcxx compatibility with libstdc++

[David Chisnall via cfe-dev]

On 9 Aug 2016, at 14:53, Jonathan Roelofs via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Yes.
> 
>> Is there any way we can work around this to link c++
>> programs compiled with libcxx against system libraries which are
>> compiled with gcc?
> 
> "compiled with gcc" isn't the issue. The issue is that you have one set of objects *built against libstdc++* and you're trying to link them against another set *built against libcxx*. This can only work if your interface between them does not contain things from the standard library.
> 
> Let me re-iterate: it is ok to link against both standard libraries (their symbols won't collide). What's not going to work is to use the headers from one library against the binaries from the other.

More specifically:

- It is not likely to be okay to mix libsupc++ (typically statically linked with libstdc++) and libc++abi in the same process.  They declare the same symbols and stuff is likely to break in exciting ways due to the conflicts.  We solved this in FreeBSD by linking both libstdc++ and libc++ against libcxxrt.  Other Linux distros have solved it by linking libc++ to libstdc++.

- It is fine to mix libstdc++ and libc++ in the same program, but it is *not* fine to pass standard library objects across library boundaries between parts of the code that use libstdc++ and parts that use libc++.  You can not, for example, pass a std::string from a program using libc++ to a library using libc++.  Most of these will result in link failures, but there are some cases that will just cause exciting run-time failures when you either bypass the type system, expect dynamic_cast (or any_cast) to work, or throw standard library objects other than std::exception in between different parts of the code.

David