dynamic_cast from base to another parent of derived class

[Boris]

I'm porting code from Windows to UNIX and ran into a problem with
dynamic_cast. Imagine a class hierarchy with three levels: class Level2
derives from Level1 which derives from Base. If you look now at this code:

Base *b = new Level2();
Level1 *l1 = dynamic_cast<Level1*>(b);

Should dynamic_cast return a valid pointer or 0? I wonder as Visual Studio
2005 returns a valid pointer while g++ 3.4.6 returns 0. Both compilers work
as expected when dynamic_cast<Level2*is used but return different results
with the code above. Who is right?

The class hierarchy I'm talking about has some more classes per level.
That's why sometimes a dynamic_cast to a level 1 class is preferred as you
can then operate on various level 2 classes which are all derived from the
same level 1 class. If you have to downcast to the actual level 2 class you
end up writing the same code for several level 2 classes which I would like
to avoid.

Boris

[Pete Becker]

Boris wrote:

I'm porting code from Windows to UNIX and ran into a problem with
dynamic_cast. Imagine a class hierarchy with three levels: class Level2
derives from Level1 which derives from Base. If you look now at this code:

Base *b = new Level2();
Level1 *l1 = dynamic_cast<Level1*>(b);

Should dynamic_cast return a valid pointer or 0? I wonder as Visual Studio
2005 returns a valid pointer while g++ 3.4.6 returns 0. Both compilers work
as expected when dynamic_cast<Level2*is used but return different results
with the code above. Who is right?

If Base has at least one virtual function (a prerequisite for applying
dynamic_cast to a Base*) and that the various bases are public,
dynamic_cast<Level1*>(b) does just what you would expect: it returns a
pointer to the Level1 subobject in the original Level2 object.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

[Boris]

Pete Becker wrote:

Boris wrote:

>I'm porting code from Windows to UNIX and ran into a problem with
dynamic_cast. Imagine a class hierarchy with three levels: class
Level2 derives from Level1 which derives from Base. If you look now
at this code: Base *b = new Level2();
Level1 *l1 = dynamic_cast<Level1*>(b);

Should dynamic_cast return a valid pointer or 0? I wonder as Visual
Studio 2005 returns a valid pointer while g++ 3.4.6 returns 0. Both
compilers work as expected when dynamic_cast<Level2*is used but
return different results with the code above. Who is right?

If Base has at least one virtual function (a prerequisite for applying
dynamic_cast to a Base*) and that the various bases are public,
dynamic_cast<Level1*>(b) does just what you would expect: it returns a
pointer to the Level1 subobject in the original Level2 object.

Thanks for your reply, Pete! When I create a small test program which works
with the original class hierarchy there is no problem with dynamic_cast.

The code I talk about looks like this:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

There is an explicit check (b is a reference to an instance of Base here)
before dynamic_cast is used. The requirements you mentioned above are also
met (Base has virtual functions and public inheritance is used everwhere).
The compiler doesn't complain either when it sees this code. When I
dynamic_cast to level2* I get a valid pointer, too. I play around some more
to figure out what's going on. If you or anyone else has an idea what might
affect dynamic_cast I would be happy to hear it!

Boris

[mlimber]

Boris wrote:

Pete Becker wrote:

Boris wrote:

I'm porting code from Windows to UNIX and ran into a problem with
dynamic_cast. Imagine a class hierarchy with three levels: class
Level2 derives from Level1 which derives from Base. If you look now
at this code: Base *b = new Level2();
Level1 *l1 = dynamic_cast<Level1*>(b);

Should dynamic_cast return a valid pointer or 0? I wonder as Visual
Studio 2005 returns a valid pointer while g++ 3.4.6 returns 0. Both
compilers work as expected when dynamic_cast<Level2*is used but
return different results with the code above. Who is right?

If Base has at least one virtual function (a prerequisite for applying
dynamic_cast to a Base*) and that the various bases are public,
dynamic_cast<Level1*>(b) does just what you would expect: it returns a
pointer to the Level1 subobject in the original Level2 object.

Thanks for your reply, Pete! When I create a small test program which works
with the original class hierarchy there is no problem with dynamic_cast.

The code I talk about looks like this:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

There is an explicit check (b is a reference to an instance of Base here)
before dynamic_cast is used. The requirements you mentioned above are also
met (Base has virtual functions and public inheritance is used everwhere).
The compiler doesn't complain either when it sees this code. When I
dynamic_cast to level2* I get a valid pointer, too. I play around some more
to figure out what's going on. If you or anyone else has an idea what might
affect dynamic_cast I would be happy to hear it!

Boris

One syntactic simplification:

if ( const level1 *const l1 = dynamic_cast<const level1*>(&b) )
{
// Use l1 here
}
else
{
// l1 is null here
}

Cheers! --M

[Boris]

Boris wrote:

[...] The code I talk about looks like this:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

I changed the code for testing purposes and replaced dynamic_cast with
reinterpret_cast - this works.

I changed then the code to make it look like this:

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

This works, too. Is there any other possible explanation than a compiler bug
why a dynamic_cast<const level1*should not work?

Boris

[Boris]

[crossposted to gnu.g++.help]

Boris wrote:

Boris wrote:

>[...] The code I talk about looks like this:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

I changed the code for testing purposes and replaced dynamic_cast with
reinterpret_cast - this works.

I changed then the code to make it look like this:

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

This works, too. Is there any other possible explanation than a
compiler bug why a dynamic_cast<const level1*should not work?

It looks like a problem with g++. The code I was talking about is in a
shared library. When I link the executable statically dynamic_cast works.
When I use however the shared library dynamic_cast returns 0. Same code but
different behavior due to linking.

There is a section "dynamic_cast, throw, typeid don't work with shared
libraries" at http://gcc.gnu.org/faq.html#dso. From what I understand though
there is not much you can do? I'm using version 3.4.6 of g++ which is the
latest of the 3.4.x series.

The code construct as above with dynamic_cast is used in various project
files. When building and linking the shared library some work, others don't.
I don't know though on what it depends why some dynamic_casts don't work and
falsely return 0. Is there anything I can do except replacing all
dynamic_casts? Any g++ experts with ideas?

Boris

[Maxim Yegorushkin]

Boris wrote:

[crossposted to gnu.g++.help]

Boris wrote:

Boris wrote:

[...] The code I talk about looks like this:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

I changed the code for testing purposes and replaced dynamic_cast with
reinterpret_cast - this works.

I changed then the code to make it look like this:

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

This works, too. Is there any other possible explanation than a
compiler bug why a dynamic_cast<const level1*should not work?

Why not just:

if(level2 const* l2 = dynamic_cast<level2 const*>(&b))
{
// no need comparing typeinfo's
}

?

>
It looks like a problem with g++. The code I was talking about is in a
shared library. When I link the executable statically dynamic_cast works.
When I use however the shared library dynamic_cast returns 0. Same code but
different behavior due to linking.

There is a section "dynamic_cast, throw, typeid don't work with shared
libraries" at http://gcc.gnu.org/faq.html#dso.

I wonder how you reached such a conclusion. Where on that page do they
say it does not work?

[Boris]

Maxim Yegorushkin wrote:

[...]

Why not just:

if(level2 const* l2 = dynamic_cast<level2 const*>(&b))
{
// no need comparing typeinfo's
}

?

I want to cast to a level 1 class which is a parent of several level 2
classes. Otherwise you are right - I could cast to the actual type directly.
The real code looks more like this:

if (typeid(b) == typeid(level2a) || typeid(b) == typeid(level2b) ||
typeid(b) == typeid(level2c))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

Class level1 is the parent of all the level2 classes. I have to check for
several types but don't need to write the same code then at least for all
the level2 classes.

>It looks like a problem with g++. The code I was talking about is in
a shared library. When I link the executable statically dynamic_cast
works. When I use however the shared library dynamic_cast returns 0.
Same code but different behavior due to linking.

There is a section "dynamic_cast, throw, typeid don't work with
shared libraries" at http://gcc.gnu.org/faq.html#dso.

I wonder how you reached such a conclusion. Where on that page do they
say it does not work?

The title is pretty clear I think: "dynamic_cast,throw, typeid don't work
with shared libraries". :-) They are talking about template instantiations,
vague linkage, not an exhaustive list, namesspaces etc. This all doesn't
sound like adding a linker switch fixes all your problems. This sounds like
be ready for all kind of problems.

Anyway if I can downcast to the actual type and then back to its parent with
the following code (no compilation error, no runtime error) why should a
dynamic_cast to the parent l1 not work?

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

Boris

[Boris]

Boris wrote:

>I wonder how you reached such a conclusion. Where on that page do
they say it does not work?

The title is pretty clear I think: "dynamic_cast,throw, typeid don't
work with shared libraries". :-) They are talking about template
instantiations, vague linkage, not an exhaustive list, namesspaces
etc. This all doesn't sound like adding a linker switch fixes all
your problems. This sounds like be ready for all kind of problems.

Anyway if I can downcast to the actual type and then back to its
parent with the following code (no compilation error, no runtime
error) why should a dynamic_cast to the parent l1 not work?

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

I changed the code to use boost::polymorphic_downcast instead of
dynamic_cast:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = boost::polymorphic_downcast<const level1*>(&b);
}

With NDEBUG defined boost::polymorphic_downcast uses only static_cast - this
works. Without NDEBUG defined dynamic_cast is used which doesn't work (as an
assert fails).

Summary: Everything works with reinterpret_cast and static_cast or
dynamic_cast when statically linked. It fails when dynamic_cast is used in a
shared library. It can not be reproduced with a small test case as
everything works then. The project I port to UNIX uses dynamic_casts in
different files where some do work. There must be some more conditions which
make g++ produce wrong code and which make some dynamic_casts fail
constantly.

Boris

[Maxim Yegorushkin]

Boris wrote:

Maxim Yegorushkin wrote:

[...]

Why not just:

if(level2 const* l2 = dynamic_cast<level2 const*>(&b))
{
// no need comparing typeinfo's
}

?

I want to cast to a level 1 class which is a parent of several level 2
classes. Otherwise you are right - I could cast to the actual type directly.
The real code looks more like this:

if (typeid(b) == typeid(level2a) || typeid(b) == typeid(level2b) ||
typeid(b) == typeid(level2c))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

Class level1 is the parent of all the level2 classes. I have to check for
several types but don't need to write the same code then at least for all
the level2 classes.

I would redesign my hierarchy so, that dynamic_cast would be enough.

It looks like a problem with g++. The code I was talking about is in
a shared library. When I link the executable statically dynamic_cast
works. When I use however the shared library dynamic_cast returns 0.
Same code but different behavior due to linking.

There is a section "dynamic_cast, throw, typeid don't work with
shared libraries" at http://gcc.gnu.org/faq.html#dso.

I wonder how you reached such a conclusion. Where on that page do they
say it does not work?

The title is pretty clear I think: "dynamic_cast,throw, typeid don't work
with shared libraries". :-) They are talking about template instantiations,
vague linkage, not an exhaustive list, namesspaces etc. This all doesn't
sound like adding a linker switch fixes all your problems. This sounds like
be ready for all kind of problems.

This is a title of a frequently asked question. The answer is given fow
to make it work. If you can follow the first advise, which is

<q>
For a program which is linked against a shared library, no additional
precautions are needed
</q>

then no other action is required.

Anyway if I can downcast to the actual type and then back to its parent with
the following code (no compilation error, no runtime error) why should a
dynamic_cast to the parent l1 not work?

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

You could find more help if you posted simplified complete code that
reproduces what you are observing.

It might be that you derive privately from your base (class A : B {};)
.. dynamic_cast in this case does not work, reinterpret_cast does work
if your base class is first in the list of the base classes.

[Boris]

Maxim Yegorushkin wrote:

[...]

>if (typeid(b) == typeid(level2a) || typeid(b) == typeid(level2b) ||
typeid(b) == typeid(level2c))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

Class level1 is the parent of all the level2 classes. I have to
check for several types but don't need to write the same code then
at least for all the level2 classes.

I would redesign my hierarchy so, that dynamic_cast would be enough.

I'm open for any suggestions but don't know if I can simplify it. If you
have a function like this:

base *foo();

which returns a level2 class but you know that level2 classes are grouped
then you try to find their parent classes (level1) if in the current
function you don't need to work with level2 classes (of course there are
other functions which need to; thus I can't get rid of any level).

It's not an option either to change the return type of foo() as there are
quite a lot of functions which all work with base classes. It must be
possible to nest them like in bar(foo()). No matter what foo() returns bar()
must be able to work with. And no matter what function is nested it must
return base* to bar().

[...]
This is a title of a frequently asked question. The answer is given
fow to make it work. If you can follow the first advise, which is

<q>
For a program which is linked against a shared library, no additional
precautions are needed
</q>

then no other action is required.

That's what I have and how I ran into this problem: It's a console program
linked to a shared library.

>Anyway if I can downcast to the actual type and then back to its
parent with the following code (no compilation error, no runtime
error) why should a dynamic_cast to the parent l1 not work?

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

You could find more help if you posted simplified complete code that
reproduces what you are observing.

I had created a small test case but unfortunately it worked. The project I
port is too large - it would take some time to track this down which I don't
have currently.

It might be that you derive privately from your base (class A : B {};)
. dynamic_cast in this case does not work, reinterpret_cast does work
if your base class is first in the list of the base classes.

But why does it all work then when I link statically?

Boris

[Maxim Yegorushkin]

Boris wrote:

[]

I had created a small test case but unfortunately it worked. The project I
port is too large - it would take some time to track this down which I don't
have currently.

So, it's not a gcc problem, is it?

[Fred Zwarts]

"Boris" <bo***@gtemail.netwrote in message news:4o************@individual.net...

[crossposted to gnu.g++.help]

Boris wrote:

>Boris wrote:

>>[...] The code I talk about looks like this:

if (typeid(b) == typeid(level2))
{
const level1 *l1 = dynamic_cast<const level1*>(&b);
}

I changed the code for testing purposes and replaced dynamic_cast with
reinterpret_cast - this works.

I changed then the code to make it look like this:

if (typeid(b) == typeid(level2))
{
const level2 *l2 = dynamic_cast<const level2*>(&b);
const level1 *l1 = l2;
}

This works, too. Is there any other possible explanation than a
compiler bug why a dynamic_cast<const level1*should not work?

It looks like a problem with g++. The code I was talking about is in a
shared library. When I link the executable statically dynamic_cast works.
When I use however the shared library dynamic_cast returns 0. Same code but
different behavior due to linking.

There is a section "dynamic_cast, throw, typeid don't work with shared
libraries" at http://gcc.gnu.org/faq.html#dso. From what I understand though
there is not much you can do? I'm using version 3.4.6 of g++ which is the
latest of the 3.4.x series.

The code construct as above with dynamic_cast is used in various project
files. When building and linking the shared library some work, others don't.
I don't know though on what it depends why some dynamic_casts don't work and
falsely return 0. Is there anything I can do except replacing all
dynamic_casts? Any g++ experts with ideas?

Boris

Interesting. A few years ago I had a similar problem on an OpenVMS system.
The dynamic_cast did not work properly in a function that was called from
another function in a shareable image (which is similar to a dynamic library
under Linux). An example was code running in a separate thread. Since the
pthread library was in a shareable image, functions running in another thread
were called from functions in a shareable image.
The OpenVMS engineers brought out a patch for the compiler and the run-time
library quickly.

The similarity of these problems strikes me, as the compiler environments are
from very different teams. Apparently there is something in dynamic_cast
that makes it difficult to work from pre-linked parts of a program.

Fred.Zwarts.

[Boris]

Maxim Yegorushkin wrote:

Boris wrote:

[]

>I had created a small test case but unfortunately it worked. The
project I port is too large - it would take some time to track this
down which I don't have currently.

So, it's not a gcc problem, is it?

Just because a small test case works doesn't mean that the compiler is
bug-free. There must be some side conditions which make the bug appear. And
I don't have the time unfortunately to find the exact conditions under which
the bug can be reproduced. Again I repeat that the same souce code linked
statically works perfectly. Thus it could be a problem with the linker,
too - I don't know.

Boris

[Boris]

Fred Zwarts wrote:

[...]
Interesting. A few years ago I had a similar problem on an OpenVMS
system.
The dynamic_cast did not work properly in a function that was called
from
another function in a shareable image (which is similar to a dynamic
library
under Linux). An example was code running in a separate thread. Since
the
pthread library was in a shareable image, functions running in
another thread
were called from functions in a shareable image.
The OpenVMS engineers brought out a patch for the compiler and the
run-time
library quickly.

The similarity of these problems strikes me, as the compiler
environments are
from very different teams. Apparently there is something in
dynamic_cast
that makes it difficult to work from pre-linked parts of a program.

Could you easily reproduce the problem with a small test program or was it
something where some other conditions had to be met? And did you ever try to
link everything statically just to see if the problem disappeared?

Boris

[Maxim Yegorushkin]

Boris wrote:

Maxim Yegorushkin wrote:

Boris wrote:

[]

I had created a small test case but unfortunately it worked. The
project I port is too large - it would take some time to track this
down which I don't have currently.

So, it's not a gcc problem, is it?

Just because a small test case works doesn't mean that the compiler is
bug-free.

True.

You have to come up with a test case to prove that the compiler is
faulty rather than your code.

[iftekhar]

just curious. You never mentioned the linker options. did you use the
-rdynamic option for linking the executable?
I had a similar problem a year back. which was solved by using
-rdynamic, if i can remember properly.

Iftekhar

[Fred Zwarts]

"Boris" <bo***@gtemail.netwrote in message news:4o************@individual.net...

Fred Zwarts wrote:

>[...]
Interesting. A few years ago I had a similar problem on an OpenVMS
system.
The dynamic_cast did not work properly in a function that was called
from
another function in a shareable image (which is similar to a dynamic
library
under Linux). An example was code running in a separate thread. Since
the
pthread library was in a shareable image, functions running in
another thread
were called from functions in a shareable image.
The OpenVMS engineers brought out a patch for the compiler and the
run-time
library quickly.

The similarity of these problems strikes me, as the compiler
environments are
from very different teams. Apparently there is something in
dynamic_cast
that makes it difficult to work from pre-linked parts of a program.

Could you easily reproduce the problem with a small test program or was it
something where some other conditions had to be met? And did you ever try to
link everything statically just to see if the problem disappeared?

It could not be reproduced in a small program, because it only occurred in
functions called from the shareable image. So, the test program needed
to use some library functions which in turn called the function in which
dynamic_cast was used, which is not easy to do in a small test program.
I encountered the bug when using the pthreads library, exactly a case where
functions in a program (the start functions of the threads) are called from the
library.
At the time I encountered the bug, it was already known to the OpenVMS
compiler group, so I did not have to prove it with a small program, but they
recognized the case and sent me the patch.
So, the conditions under which the bug was exposed were not determined by me,
but I read them in the patch description. It gave an excellent explanation why
dynamic_cast worked in some cases, but failed in others.

Fred.Zwarts.

[Boris]

iftekhar wrote:

just curious. You never mentioned the linker options. did you use the
-rdynamic option for linking the executable?
I had a similar problem a year back. which was solved by using
-rdynamic, if i can remember properly.

I rebuilt everywhing with the default compiler and linker switches. No -f
options or anything else which might affect compiling and linking. I tried
to build the executable with and without -rdynamic (which I never heard of
before and couldn't find in the local man files either). It all didn't help.
The only thing which works is linking statically (which doesn't help me
really as I need to ship a library).

Boris

[F.J.K.]

Boris wrote:

I had created a small test case but unfortunately it worked. The project I
port is too large - it would take some time to track this down which I don't
have currently.

Is the bug present in GCC 4.x?
in mainline?

Is there any reason you can't just do? (Real question, not just
rhetorical :-)

#ifdef __GNUC__ && __GNU__<4
#define dynamic_cast static_cast
#endif

>From what I take from the discussion so far, you have assured your code

is semantically correct (See Pete Beckers guru-posting). At this point,
I'd just truy to work around and go on with life.

[Boris]

F.J.K. wrote:

Boris wrote:

>I had created a small test case but unfortunately it worked. The
project I port is too large - it would take some time to track this
down which I don't have currently.

Is the bug present in GCC 4.x?
in mainline?

I don't know, I didn't try yet. For now I'm happy if I can work around the
bug and finally release the software on Linux.

Is there any reason you can't just do? (Real question, not just
rhetorical :-)

#ifdef __GNUC__ && __GNU__<4
#define dynamic_cast static_cast
#endif

Yes, I use something like this now:

#if defined(__GNUC__)
const level1 &l1 = *static_range<const level1*>(&base);
#else
const level1 &l1 = dynamic_cast<const level1&>(base);
#endif

>From what I take from the discussion so far, you have assured your
code

is semantically correct (See Pete Beckers guru-posting). At this

I'm as much sure as you can be with C++ code. ;-) What's 100% for sure
though is that everything works when linked statically.

Boris

[skaller]

On Wed, 04 Oct 2006 00:41:36 +0300, Boris wrote:

>This works, too. Is there any other possible explanation than a
compiler bug why a dynamic_cast<const level1*should not work?

It looks like a problem with g++. The code I was talking about is in a
shared library. When I link the executable statically dynamic_cast works.
When I use however the shared library dynamic_cast returns 0. Same code but
different behavior due to linking.

There is a section "dynamic_cast, throw, typeid don't work with shared
libraries" at http://gcc.gnu.org/faq.html#dso. From what I understand though
there is not much you can do? I'm using version 3.4.6 of g++ which is the
latest of the 3.4.x series.

Boris, this is a very general problem in C++, coupled with
both compiler, library, and linker problems. It's all about
requirements for uniqueness.

Here is a formula to make it all work reliably,
but first definitions:

A *module* is either a shared library or executable

A type is *critical* if it is shared between modules
and must be unique.

* Do not use inline functions for critical types
-- this forces the RTTI and vtable to be in
a specific object file

* if two libraries A,B share some critical entity X, X must
be instantiated in a third library D on which
both A and B depend: they must be linked against D
at compile time.

If you follow these rules everything will work.

You can relax the first rule if you know what member functions
haul in the vtable/rtti.

Example: you have three libraries A, B, and C which are
loaded as plugins in various combinations, and can be
unloaded too! They communicate by dynamic casting or
exceptions, for a type X.

Make sure there is a library D containing X.
Link A,B,C against D.

If you do this, there will be ONE instance of X in D,
and D will remain loaded whilst any one of A,B,C is
loaded. D may be unloaded and reloaded if A,B,C
are all unloaded, and X may end up with a different
address in that case, but you cannot tell except
by 'cheating' such as saving the address as a void*
in the mainline. If that happens .. well you broke
the second rule, since the mainline actually
depended on X and you didn't link D to it in such
a way the dependence is manifest, which is what
the second rule requires. This is very unlikely
to happen, except with debugging code.
--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net

[Maxim Yegorushkin]

skaller wrote:

Boris, this is a very general problem in C++, coupled with
both compiler, library, and linker problems. It's all about
requirements for uniqueness.

Here is a formula to make it all work reliably,
but first definitions:

A *module* is either a shared library or executable

A type is *critical* if it is shared between modules
and must be unique.

* Do not use inline functions for critical types
-- this forces the RTTI and vtable to be in
a specific object file

* if two libraries A,B share some critical entity X, X must
be instantiated in a third library D on which
both A and B depend: they must be linked against D
at compile time.

If you follow these rules everything will work.

What about weak symbols? Do not they exist to solve this very problem
when multiple modules export the same symbol? If a symbol is a weak
symbol in all the modules, which is true for typeinfo objects, all the
references to that symbol are resolved to the first one found by ld.so.
Am I missing something?