http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #20 from Michael Matz <matz at gcc dot gnu.org> 2012-06-21 15:25:59 UTC --- As I stumbled over this problem complex recently already I had a hunch that it might again be a 11/98 mixture. Having the symbols would have made that a certainty. But it wouldn't have helped me that much further. I still would have had to find out which functions were causing the wild write (after all, an 11/98 mixture in itself is not the problem, the library authors for instance might have controlled their exports) in order to say with confidence that this is really the cause for the problem, and not something like a normal program error. Of course if the implementation of PR 53673 would make it so, that such programs can't even be link edited or if so, then at least not be run (the dynamic linker could throw an error for instance) then this problem wouldn't have turned up. OTOH, that's fairly unforgiving and could still be worked around by the user by for instance specifically hiding such magic symbol. (Although, if he's able to hide that magic symbol he should also be able to hide all the other reexported libstdc++ symbols). I btw. wonder if all these weak symbols of libstdc++, that right now are reexported by default, shouldn't get hidden visibility. Would make (non-inlined) calls faster, and avoid the cross-c++-std-domain resolving leading to this problem. At least on targets that support visibility.
