Re: [Opensync-devel] python wrapper and plugin

[Mark E. <ma...@mp...>]

On Mon, 2012-08-13 at 19:58 +0200, Chris Frey wrote:
> On Mon, Aug 13, 2012 at 03:46:51PM +0100, Mark Ellis wrote:
> > Found the problem. In opensync/module/opensync_module.c, the call to
> > g_module_open() uses the BIND_LOCAL flag, restricting the symbols from
> > the global namespace, which is not used in opensync 0.22. Removing the
> > flag resolves my symbol problem.
> > 
> > However, was this flag added for a good reason ? It was added in svn
> > revision 4396, and the reasoning makes sense, but I don't know whether
> > that was actually a real problem at the time. If the flag is necessary,
> > that makes python embedding somewhat difficult.
> 
> Yes, that's definitely there for a reason.  It makes it hard to control
> what symbols are loaded without the LOCAL flag.
> 
> My personal opinion is that it's much cleaner to use LOCAL... almost like
> a namespace at the linker level.  And according to Python, namespaces
> are a good thing. :-)
> 
> 
> > The first thing the synce plugin does is import some more python
> > modules. The first being dbus, which in turn imports most of it's
> > functionality from a C shared object. Quite correctly as I understand
> > it, this object is not linked to libpython, and results in a python
> > import error from undefined symbols. I first tried passing -Xlinker
> > -export-dynamic when linking the python plugin, which didn't help,
> > annoying since this seems to be the accepted way of fixing this.
> > LD_PRELOAD with libpython fixes it, confirming everything else is ok,
> > but the python plugin is linked to libpython, so it should already be
> > loaded.
> 
> The undefined symbols... are they only libpython symbols?
> 
> If I import dbus in the sample.py, will I see what you see, or do I need
> to actually use it somehow?
> 

Yes you'll see it if you just import dbus. No other unresolved symbols,
the python extension objects are linked against all the other libs they
need, just not libpython.

Mark