[C++-sig] Re: exceptions and multiple modules
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
> 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.
> 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
> 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
> 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>
More information about the Cplusplus-sig