GNOME Bugzilla – Bug 374603
pygtk does not run when configuring with --disable-thread
Last modified: 2011-01-28 08:36:27 UTC
Please describe the problem: When using ./configure --without-threads, undefined references to PyGILState_Ensure/Release will be generated in gobject.so, since when python is built also --without-threads, these symbols are not present. Steps to reproduce: 1. build python --without-threads 2. build pygtk --without-threads 3. run python, and enter 'import gtk' Actual results: import gobject as _gobject ImportError: /prefix/python/lib/python2.4/site-packages/gtk-2.0/gobject.so: undefined symbol: PyGILState_Ensure Expected results: Success, no output Does this happen every time? Yes Other information: I'll file a patch fixing this issue, please consider for inclusion, thanks.
Well, trying to add an attachment mad bugzilla generate an internal error, so here is a copy/paste. Patch is simple enough to be applied manually anyway: --- gobject/gobjectmodule.c.old 2006-11-12 13:45:27.445909011 +0100 +++ gobject/gobjectmodule.c 2006-11-12 13:46:36.515561908 +0100 @@ -1942,13 +1942,19 @@ pyg_enable_threads (void) static int pyg_gil_state_ensure_py23 (void) { +#ifdef DISABLE_THREADING + return 0; +#else return PyGILState_Ensure(); +#endif } static void pyg_gil_state_release_py23 (int flag) { +#ifndef DISABLE_THREADING PyGILState_Release(flag); +#endif } static PyObject * --- gobject/pygobject-private.h.old 2006-11-12 13:46:59.546112716 +0100 +++ gobject/pygobject-private.h 2006-11-12 13:51:23.940955354 +0100 @@ -21,12 +21,18 @@ extern struct _PyGObject_Functions pygob #define pyg_threads_enabled (pygobject_api_functions.threads_enabled) +#ifdef DISABLE_THREADING +#define pyg_gil_state_ensure() 0 +#define pyg_gil_state_release(state) G_STMT_START { \ + } G_STMT_END +#else #define pyg_gil_state_ensure() (pygobject_api_functions.threads_enabled? (PyGILState_Ensure()) : 0) #define pyg_gil_state_release(state) G_STMT_START { \ if (pygobject_api_functions.threads_enabled) \ PyGILState_Release(state); \ } G_STMT_END +#endif #define pyg_begin_allow_threads \ G_STMT_START { \ --- gobject/pygobject.h.old 2006-11-12 13:47:06.629974549 +0100 +++ gobject/pygobject.h 2006-11-12 13:50:38.854834887 +0100 @@ -244,6 +244,12 @@ struct _PyGObject_Functions *_PyGObject_ #define pyg_threads_enabled (_PyGObject_API->threads_enabled) +#ifdef DISABLE_THREADING +#define pyg_gil_state_ensure() 0 +#define pyg_gil_state_release(state) G_STMT_START { \ + } G_STMT_END + +#else #define pyg_gil_state_ensure() \ (_PyGObject_API->threads_enabled ? \ (PyGILState_Ensure()) : 0) @@ -251,6 +257,7 @@ struct _PyGObject_Functions *_PyGObject_ if (_PyGObject_API->threads_enabled) \ PyGILState_Release(state); \ } G_STMT_END +#endif #define pyg_begin_allow_threads \ G_STMT_START { \
Fixing subject line: the configure option is --disable-thread with pygtk (and --without-threads for python). Arno
Could someone review and apply the proposed patch ? It's only minutes of work for a good soul. Thanks in advance. Arno
Is there nobody looking at this bug ? If so, I guess I'll close this PR, let me know. Arno
If you still care about this, please provide a patch against newer PyGObject: current is badly outdated. Also, please attach it.
Created attachment 133195 [details] [review] updated patch The patch really hasn't changed, it just now needs to be applied to pygobject, see attachment.
Created attachment 133196 [details] [review] cleaned up patch The previous patch contained an extra change which is not part of this PR, please ignore and consider this new attahcment instead, thanks.
Comment on attachment 133196 [details] [review] cleaned up patch This is a patch against some released version. It doesn't apply against the trunk.
Created attachment 138890 [details] [review] updated patch against pygobject 2.18.0 Looking at 2.18.0, most the of the original patch now looks obsolete, here is what's left. TIA.
Created attachment 138894 [details] [review] better version of patch against pygobject 2.18.0 Previous patch was incomplete, this one works.
Is this still an issue?
Well yes, --disable-thread is still broken and apparently nobody seems to care. I'd suggest either fixing it or removing this capability altogether.
Review of attachment 138894 [details] [review]: Looks good.
The following fix has been pushed: a4b210d Disable calls to PyGILState_* when threads are disabled
Created attachment 178644 [details] [review] Disable calls to PyGILState_* when threads are disabled Since threads may also be disabled in Python too, those symbols may not be resolved.
*** Bug 640748 has been marked as a duplicate of this bug. ***