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

[Ben Young]

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

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.

Thanks for the help

Ben
---