On 24 Mar 2016, at 13:42, Damjan Jovanovic <damjan.jov_at_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. DavidReceived on Thu Mar 24 2016 - 12:56:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC