[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
concerned.

> 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
www.boost-consulting.com





More information about the Cplusplus-sig mailing list