On 24 Mar 2016, at 13:42, Damjan Jovanovic <damjan....@gmail.com> wrote:
> ELF itself is a disaster. Symbol lookup in ELF is process scoped, not
> library scoped like Windows's PE and Mac's Mach-O, so same named
> symbols from different libraries in the same process (loaded through
> any number of levels of indirection) can and do clash, resulting in
> memory corruption. This is why hacks like symbol versioning,
> RTLD_DEEPBIND on GNU's libc and -Bdirect on Solaris were invented.
This problem is addressed by some of the work that Sony has done recently that
they are about to upstream to Clang/LLVM.
> We suffer from this problem badly on FreeBSD, as Clang's C++ standard
> library and GCC's standard library don't have fully compatible ABIs,
> so when both are loaded into the same process and the incompatible C++
> features are used -> memory corruption -> crash. Eg. compile Apache
> OpenOffice with GCC on a system built with Clang, and you'll see even
> the unit tests crash.
That shouldn’t happen, as libstd++ and libc++ have different symbols (libc++
puts its symbols in the __v1 namespace). The problem can come from mixing
libsupc++ and libcxxrt, but that’s only an issue if you have not built
libstdc++ against libcxxrt.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"