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. Question: 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 ------- Answer: 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 from. 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 -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpTksQAd6Qop.pgp
Description: PGP signature
