After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659775 - commit "Bind module symbols locally and immediately" breaks python loader
commit "Bind module symbols locally and immediately" breaks python loader
Status: RESOLVED FIXED
Product: libpeas
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: libpeas-maint
libpeas-maint
Depends on:
Blocks:
 
 
Reported: 2011-09-21 23:40 UTC by Gert Kulyk
Modified: 2011-09-23 08:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dlopen (567 bytes, patch)
2011-09-22 16:44 UTC, Ignacio Casal Quinteiro (nacho)
none Details | Review

Description Gert Kulyk 2011-09-21 23:40:41 UTC
After pygobject 3.0 was released, I updated my libpeas-installation, too. But neither git master nor the released tarball allowed me to load python plugins, because python loader was not able to import the gobject stuff due to missing symbols (which are part of libpython2.x). Because libpeas 1.1.3 was working fine, I looked over the changes since then, to find out what causes the breakage. I found commit 79c456ebf232f5de66c15580fff20885dee0bae6 responsible for it - obviously python needs 'G_MODULE_BIND_LAZY' to get the symbols resolved properly.
Comment 1 Garrett Regier 2011-09-21 23:59:46 UTC
Except that is only used for C plugin...

Others have said that they cannot import pygobject but that seems to have something to do with your pygobject install.
Comment 2 Gert Kulyk 2011-09-22 01:05:23 UTC
I did not really check how the mentioned code works, but the mentioned commit must be somehow related to the python loader, because changing G_MODULE_BIND_LOCAL back to G_MODULE_BIND_LAZY in peas-object-module.c causes my python plugins in gedit, rhythmbox etc. (and in peas-demo, too) to work while not doing so causes a failure (believe me, I compiled the recent pygobject and libpeas versions many times with different options (system-wide and in jhbuild-environment), and only reverting the mentioned commit makes pygobject and libpeas work here.)
Comment 3 Ignacio Casal Quinteiro (nacho) 2011-09-22 10:23:32 UTC
Same problem here.
Comment 4 Ignacio Casal Quinteiro (nacho) 2011-09-22 10:25:50 UTC
IMHO I think this is because there is some problem in pygobject but I'm not totally sure. Although changing it back to lazy and try to find out the problem for 1.4 wouldn't be much of a problem.
Comment 5 Gert Kulyk 2011-09-22 12:54:52 UTC
The only problem in pygobject that I can find is, that libpyglib-gi-2.0-python2.*.so.* uses symbols from libpython2.x not beeing linked against it directly but dlopening it. G_MODULE_BIND_LOCAL in peas-object-module.c works only when preloading libpython2.x.
Comment 6 Ignacio Casal Quinteiro (nacho) 2011-09-22 12:56:39 UTC
I agree, we should just use 0 as flags so the dlopen uses global as flag. This means that it is load locally but also subsequentialy.
Comment 7 Ignacio Casal Quinteiro (nacho) 2011-09-22 16:44:32 UTC
Created attachment 197265 [details] [review]
dlopen

This is the patch.
Comment 8 johnp 2011-09-22 21:08:04 UTC
works for me
Comment 9 Gert Kulyk 2011-09-22 23:25:00 UTC
For me too.
Comment 10 Garrett Regier 2011-09-23 08:52:57 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.