Re: [Opensync-devel] python wrapper and plugin

[Chris F. <cd...@fo...>]

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?

Thanks,
- Chris