0

Unfortunately I can't post the source code for this, but I will try to set it up as best I can.

I have a case where dynamic_cast fails to cast to a derived class type, and I know it should succeed (ie, I know the actual type of the instance). Also typeid for a heap allocated object doesn't equal the typeid for a stack allocated object!! IE,

Foo mstack;
Foo*mheap = new Foo();
typeid(mstack) == typeid(*mheap);  // returns FALSE!?

So there is clearly a RTTI problem somewhere. The class implementation (for both base and derived classes) is in one shared library, the malfunctioning code is in a second shared library which is loaded as a Python module in the Python interpreter (all on linux, same problem when using either gcc 4 or Intel C++ compiler). If I write a simple little test executable that links both shared libraries, everything works fine. I've tried --export-dynamic when linking the shared libraries without success (looks like it's intended for use with executables). Anybody have any pointers for where to look? Is there something particular about the way Python uses dlopen() that causes this kind of problem?

user1372826
  • 1
  • Have you tried creating a minimal example which reproduces the problem? – Karl Knechtel May 03 '12 at 15:56
  • This is a bit vague. Your example deals with `typeid` operator however without the definition of `Foo` there is no way to determine why the comparison is evaluating to false as it wouldn't for `class Foo {};`. You then go on to describe issues with linking shared libraries and python which have little to do with this. – AJG85 May 03 '12 at 16:05
  • @AJG85 - it is unfortunately a bit vague since I am not able to include the source code. I think the linkage with python must be relevant since everything works fine when linked with a simple executable. But I'm hoping somebody out there will have some knowledge that will point me in the right direction, so any suggestions even if they are indirect would be very useful. – user1372826 May 03 '12 at 18:19
  • For posterity - at least one way to fix the problem is to force Python to load shared libraries with the RTLD_GLOBAL flag; see http://stackoverflow.com/questions/3396966/dynamic-linking-and-python-swig-c-works-in-c-fails-in-python – user1372826 May 04 '12 at 15:57

1 Answers1

0

This is caused by Python loading the extension module with RTLD_LOCAL, and the solution is to force Python to load it with RTLD_GLOBAL instead (see OP's comment).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362