On Mon, Jan 21, 2013 at 04:12:00PM +0000, David Chisnall wrote: > On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > > > Yes, quite possible. AFAIR, the 'catch' code compares the exception classes > > by the shared object ownership. It might get confused due to filter > > providing > > some symbols. > > > > But I did not investigated the cause for real. > > The issue appears to be that the libstdc++ exports a few functions[1] that > libsupc++ exports, but with different symbol versions. Unfortunately, these > are things that set handlers that are then called from libsupc++ / libcxxrt > when, for example, an exception specification violation is encountered. > > I'm not sure what the solution is here. Is there some version-script-foo > that we can do to say 'filter this symbol with this version as if it were > this one with this version'? We ideally want to keep them with the current > version in libcxxrt / libsupc++, but not introduce linker errors. > > David > > [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected()
Can you prepare the minimal isolated test case which demostrates the behaviour ? A plan would be to ask somebody to run the test on the linux. I think we must be bug-to-bug compatible with glibc in regard to the filters quirks. Gnu filters work only on the whole object scope. Solaris linkers do have per-symbol filtering, but Solaris does not implement per-symbol versioning, on the other hand.
pgpGQGG6ShR1E.pgp
Description: PGP signature
