exceptions not caught from shared libraries loaded with dlopen

[tahoma@gmx.de]

> > > Adding RTLD_GLOBAL to dlopen flags solves the problem for now. I have
> > > to investigate further. I stumbled across this behaviour while creating
> > > C++ Wrappers for Python with Swig. The order of importing the generated
> > > wrapper libraries results in different result. Exceptions thrown in C++
> > > will be caught one time the other time not. So I stripped down the
> > > generated wrapper code and tried to emulate Python's import. I do not
> > > know whether Python uses RTLD_GLOBAL when importing libraries or not.
> >
> > Sorry for bothering you with this problem.
> >  The RTLD_GLOBAL hint was very helpful and helped me to
> > solve this problem with my wrappers. One has to set this
> > flag for Python as well because it uses RTLD_LOCAL as default.
> >
> > Thanks for pointing me into the right direction,
>
> I think this is a 'bug' in the code: you should NOT use RTLD_GLOBAL.
> The correct flags are RTLD_NOW | RTLD_LOCAL.

When using RTLD_NOW | RTLD_LOCAL as default dlopen flags for Python it doesn't 
work again.

> What you MUST do is make sure all the methods of exception
> E are declared but not defined in the header file,

Yes, it is done in the real code, but not in the example I posted. The results 
are the same.

> The plugin library must be linked against the libraries that contain
> the definitions of symbols it requires, and so must every other
> library AND the application (excluding dlsym()bols of course).

When using Python for example, I cannot link Python against my own libraries. 
So thats a bit of a problem in my case.

> Since you cannot dlsym() a type, this correctly ensures you CANNOT
> catch an exception defined in a plugin. This cannot be permitted.
> (Except with ... or a shared base of course!)

That explains why I can catch std::exception which is the base of all my own 
Exceptions. It works in Python as well though it is not linked against the 
C++ libraries containing std::exception.

Jan