[Bug c++/53646] Surprising effects of cxx11 vs cxx98 ABI compatibility

["matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.