[compiz] RTLD_GLOBAL flag for dlopen

David Reveman davidr at novell.com
Mon Apr 9 12:01:29 PDT 2007

On Mon, 2007-04-09 at 18:18 +0100, Mike Dransfield wrote:
> David Reveman wrote:
> > On Mon, 2007-04-09 at 17:16 +0100, Mike Dransfield wrote:
> >   
> >> I am just experimenting with a plugin loader and I found
> >> that there are problems with external symbols which are
> >> loaded at runtime.
> >>
> >> The solution is to add RTLD_GLOBAL to the dlopen mode,
> >> but I am not sure if this would cause other problems.
> >>     
> >
> > So your plugin loader provides symbols that subsequently loaded plugins
> > use? What are those symbols and what are they used for? Maybe there's a
> > more appropriate way to provide those symbols to the plugins.
> >
> >   
> I am not actually providing symbols directly, I am linking
> to python, but not all of the symbols are being exported to
> be used by dynamically loaded python modules.

Hm, is python compiling .py compiz plugins into dynamic libraries and
then dynamically loading them while also assuming that the main program
is linked to some python library? In which case it would seem that
python should be adding any required libraries as dependencies to the
compiled plugin instead of requiring the main program to be linked to it
but maybe there's a good reason for this.

> An example is the python open gl module.  As soon as that loads
> it tries to read some python symbols which I do not use.
> I tried different ld flags but none of those seem to work.  An
> alternative is to dlopen libpython from within the loader plugin
> or preload libpython.

Yes, dlopen libpython within the loader plugin might be better than
loading all plugins with RTLD_GLOBAL flag. RTLD_GLOBAL wouldn't be too
bad but it would be nice to avoid it as plugins are more self-contained
without it and potential issues with plugins accidentally providing
symbols to other plugins are avoided.

- David

More information about the compiz mailing list