On Thursday 16 March 2006 15:24, Brian Harring wrote:
I would have called bincompat BINSLOT, but the idea is the same.

> As per the norm, requires a smart resolver; for c++ would expect
> cycles to occur where the only solution is to pull in libstdc++ (fex)
> to sidestep horkage while doing the rebuilds...

Don't start about c++. Suppose you have a library A that is build against 
libstdc++ 5, It contains a class B with a toString method that returns an 
std::string instance. Next we have application C that extends class B in 
class D. It (also) redefines the toString method. This application is 
binary and we don't have (or don't want to use) the source. It was 
however linked against libstdc++ 6.

Which std::string should class D return in it's toString method? The one 
from libstdc++5 or from libstdc++6 ?

(And for a moment disregard the fact that actually the string classes are 
binary compatible so it doesn't matter).

------ answer follows after some lines -------

There is no right answer. We have hit a situation whose solution is 
undefined. In reality this is "solved" by the fact that the dynamic 
linker does not look at which library a particular symbol (read name) is 

With linker symbol versions, what happens is that the types are silently 
cast. This however breaks runtime type information. We can namely now get 
the situation where two std::string instances do not actually have the 
same runtime type. This breaks casting. Fun isn't it.


Paul de Vrieze
Gentoo Developer
Homepage: http://www.devrieze.net

Attachment: pgpTksQAd6Qop.pgp
Description: PGP signature

Reply via email to