[Python-Dev] Problems with Python's default dlopen flags

David Abrahams David Abrahams" <david.abrahams@rcn.com
Sat, 4 May 2002 23:25:54 -0500

----- Original Message -----
From: "Andrew MacIntyre" <andymac@bullseye.apana.org.au>
> On Sat, 4 May 2002, David Abrahams wrote:
> > Did you misread my suggestion? I didn't say that RTLD_GLOBAL should
> > the default way to load an extension module, only that there should
be a
> > way for the module itself to determine how it's loaded.
> I don't want to rain on your parade, but some reasearch into dynamic
> linking loaders proves distressing:-
> - some always link globally (Windows, OS/2 as I understand);
> - the others require explicit specification of the method

This information is not new to me; I'm aware of the differences. I'm
quite familiar with the Windows model, and it's not quite global linking
in the same sense as on Unix: you explicitly specify which symbols are
designated for sharing.

> The ones that give you the choice require you to specify the method
> the first reference to the shared object is made.  If you want to
> the mode, you have to dereference all entry points and unload the SO
> before having another go.  This turns out to be nightmarish.

AFAICT that would not be a nightmare in the scenario I'm suggesting. The
initial dlopen wouldn't use RTLD_GLOBAL, so there would only be one or
two entry points to dereference before unloading the module and trying

> In addition to the shim module elsewhere referred to, I think that you
> might also be able to leverage a pure Python wrapper to import the
> modules (in effect a specialised version of the import hook wrappers
> available.

Yes, (as I'll repeat once again) this approach puts the burden on users
of the extension module to know that it needs to be imported in a
special way. That's just wrong.

> Another apprach is to use a "core" module which links all the
> bits and provides a vector of entry points which can be retrieved via
> Python API call (I forget which relatively common module I've seen
> does this).

That won't work for C++, and even if it could, it doesn't conform to my
users' needs. The symbols (not just entry points) which the compiler
generates to support RTTI and exception-handling aren't normally
available to users.