So it seems that the desktop wide decision to load all modules with
G_MODULE_BIND_LOCAL, for performance reasons, may break python
extensions. So far, nautilus-python was affected by this. Do people
have any suggestions? Clearly Python has to be fixed, but that is a
long term fix; how to fix things _now_?
On Wed, 2006-01-25 at 13:41 +, Gustavo J. A. M. Carneiro wrote:
On Wed, 2006-01-25 at 10:15 +0100, Alexander Larsson wrote:
On Wed, 2006-01-25 at 00:22 +, Gustavo J. A. M. Carneiro wrote:
Regarding this change (after 2.13.3):
2005-12-13 Alexander Larsson [EMAIL PROTECTED]
* libnautilus-private/nautilus-module.c (nautilus_module_load):
open modules G_MODULE_BIND_LOCAL
It has broken nautilus-python. See bug #327739. The problem is that
python modules expect to find some standard python symbols in the global
scope, but since nautilus is loading the nautilus-python extension
module---and consequently libpython24.so itself---in a private scope,
all python extension modules fail to load.
Any thoughts?
The whole move to BIND_LOCAL is a gnome-wide thing we're doing for
performance reasons. All other places loading modules were changed
similarly. Maybe we should discuss this in a wider scope?
I understand and generally agree with this. Python itself loads all
modules in a local scope. I remember how this used to affect some gtk
engines until they were fixed to link explicitly to gtk.
How can python module look up things in the global scope only? Surely
the nautilus-python library links to libpython, and thus all the symbols
in that should be availible to all code that nautilus-python loads?
nautilus-python library links to libpython, but both nautilus-python
library and libpython are bound to a local scope. libpython then loads
python modules, but python modules never explicitly link to libpython
(because many times there is no python dll available, only the exe).
Apparently, modules loaded by a library don't automatically use that
library's scope, but instead try to rely on the global scope.
Clearly python is broken in this respect. The python shared library
should always be available, and all python extension modules should link
to it. Then we would not have this problem. But as it is, there's
nothing we can do. I wish there was some way to open an exception just
for nautilus-python, make it load with global symbol visibility instead?
Maybe some metadata xml file. Or some special naming convention for
the library name? Yes, it's a bit hackish, I'm ashamed to suggest it :P
(Clearly I'm not an expert in these things...)
Me neither. James, maybe you can help us? :)
Regards,
--
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
