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 |