[C++-sig] Re: exceptions and multiple modules

David Abrahams dave at boost-consulting.com
Wed Jul 23 16:32:06 CEST 2003

Ben Young <ben.young at transversal.com> writes:

> On Wed, 23 Jul 2003, David Abrahams wrote:
>> Ben Young <ben.young at transversal.com> writes:
>> > We also had to use this trick to import our boost-python wrapped library.
>> > I noticed Dave Abrahams thread on python-dev about libraries being able
>> > to specify their own dlopen flags for import. Did anything ever come of
>> > this Dave?
>> Nope, it was unfortunately a wrong-headed idea, IMO.
>> > or do you think we (transversal) will have just have to keep a
>> > wrapper python script that knows how to do the import correctly?
>> I don't think using RTLD_GLOBAL for extension modules is a good idea
>> in general, and I'd encourage new users to find alternative
>> approaches.  If it's working for you, though, there's no need to
>> change.
> The only problem is that the library itself can dynamically import
> backends which use symbols in the library itself. 

Python itself has a similar relationship with its extension modules.
Seems to work out OK without RTLD_GLOBAL.

> e.g
> import mfAPI
> mfAPI.useBackend("dbserver")  # Will import the database backend
> mfAPI.useBackend("soapclient")# Will import the soapclient backend
> conn = mfAPI.Connection(...)  # Will connect to either the database server
> 			      # or the soapclient depending on the
>                               # connection params
> Every action from now on will transparently go through SOAP or the
> database depending on the params.
> The point is that the mfAPI library doesn't know anything at all about
> dbserver of soapclient before they are imported, also by dlopen.
> The c++ code is the same
> LibraryControl::import("dbserver")
> LibraryControl::import("soapclient")
> MF::Connection conn = LibraryControl::connect(...)
> conn can now be used to transparently use objects through either SOAP or
> the database. This however works as the c++ code is 
> linked at compile time
I think I know what you mean, but something's not right about that.

> to the correct base librarys and only "dbserver" or "soapclient" are
> dlopened.
> The problem seems to be that when python dlopens mfAPI, because it doesn't
> use RTLD_GLOBAL tdbserver etc can't see the symbols in mfAPI and you get
> dynamic_cast failures.

The way to handle dynamic_cast issues is to instantiate the base
class' virtual functions in a common shared library which is linked to
in the usual way (not dlopen) by all the other dynamic libraries

> Now I think i'm going round in circles explaining this anyway :) I'm sure
> there is probably a simple solution, but as you say, it works for us, and
> we only use the python bit internally at the moment.
> I am slightly worried as the mechanism ( designed here by Richard
> Smith who is quite active in comp.std.c++ ) allows us to trivially
> generate bindings to any language ( we have perl and php as well at the
> moment, though they are mouldering at the moment since I discovered python
> and pushed it on everyone else!) and I can see these problems reappearing
> for them.
> Never mind though.

Now you tell me! <wink>

Dave Abrahams
Boost Consulting

More information about the Cplusplus-sig mailing list