> > > 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
