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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz