[C++-sig] cross-module RTTI issues

[Dan Haffey]

Hello,

I'm not sure if this is even the right place to post this question, but I'm 
having some trouble with inheritance across shared library boundaries. I've 
read the CrossExtensionModuleDependencies Wiki node, and I assume that my 
problem stems from std::type_info comparison problems, so my question is 
basically: how do I go about making sure my RTTI info is all coming from the 
same place?

I'm specifically referring to this snippet from the Wiki:
"The best way to achieve that is to link both extension modules to a common 
shared library using the global model, and put the RTTI information there."

I'm not sure how exactly I get all the relevant RTTI information into that 
third library.

Just incase I'm completely off-course with my diagnosis of the problem, here's 
an example of what I'm talking about (this breaks in Linux with gcc 3.3.4):
--- A.hpp ---
struct A
{
        A() {}
        virtual int foo() = 0;
};

struct Factory
{
        Factory() {}
        virtual A* make() = 0;
};

--- A.cpp ---
#include "A.hpp"

--- B.hpp ---
#include "A.hpp"

struct B : public A
{
 B() {}
 virtual int foo();
};

struct DerivedFactory : public Factory
{
 DerivedFactory() {}
 virtual A* make();
};

--- B.cpp ---
#include "B.hpp"

int B::foo() { return 42; }
A* DerivedFactory::make() { return new B; }

--- A.pyste ---
A = Class('A', 'A.hpp')
Factory = Class('Factory', 'A.hpp')
set_policy(Factory.make, return_value_policy(reference_existing_object))

--- B.pyste ---
B = Class('B', 'B.hpp')
DerivedFactory = Class('DerivedFactory', 'B.hpp')
set_policy(DerivedFactory.make, 
return_value_policy(reference_existing_object))


And in Python:
>>> import A, B
>>> x = B.DerivedFactory().make()
>>> x.foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    B.foo(B)
did not match C++ signature:
    foo((anonymous namespace)::B_Wrapper {lvalue})
    foo(B {lvalue})
>>> x = B.B()
>>> x.foo()
42
>>>

Is there a way around this behavior, or is there just no hope for this pattern 
of shared library usage? Any help would be greatly appreciated,

--
Dan Haffey