Gentoo Archives: gentoo-portage-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] DB and binary dependency
Date: Thu, 16 Mar 2006 15:01:31
Message-Id: 200603161600.25225.pauldv@gentoo.org
In Reply to: Re: [gentoo-portage-dev] DB and binary dependency by Brian Harring
1 On Thursday 16 March 2006 15:24, Brian Harring wrote:
2 I would have called bincompat BINSLOT, but the idea is the same.
3
4 > As per the norm, requires a smart resolver; for c++ would expect
5 > cycles to occur where the only solution is to pull in libstdc++ (fex)
6 > to sidestep horkage while doing the rebuilds...
7
8 Don't start about c++. Suppose you have a library A that is build against
9 libstdc++ 5, It contains a class B with a toString method that returns an
10 std::string instance. Next we have application C that extends class B in
11 class D. It (also) redefines the toString method. This application is
12 binary and we don't have (or don't want to use) the source. It was
13 however linked against libstdc++ 6.
14
15 Question:
16 Which std::string should class D return in it's toString method? The one
17 from libstdc++5 or from libstdc++6 ?
18
19 (And for a moment disregard the fact that actually the string classes are
20 binary compatible so it doesn't matter).
21
22
23 ------ answer follows after some lines -------
24
25
26
27
28
29
30
31
32
33
34
35
36
37 Answer:
38 There is no right answer. We have hit a situation whose solution is
39 undefined. In reality this is "solved" by the fact that the dynamic
40 linker does not look at which library a particular symbol (read name) is
41 from.
42
43 With linker symbol versions, what happens is that the types are silently
44 cast. This however breaks runtime type information. We can namely now get
45 the situation where two std::string instances do not actually have the
46 same runtime type. This breaks casting. Fun isn't it.
47
48 Paul
49
50 --
51 Paul de Vrieze
52 Gentoo Developer
53 Mail: pauldv@g.o
54 Homepage: http://www.devrieze.net