libpython2.7.a(object.o): In function `_PyObject_Dump':
/home/antoine/cpython/__svn__/Objects/object.c:341: undefined reference
to `PyGILState_Ensure'
/home/antoine/cpython/__svn__/Objects/object.c:343: undefined reference
to `PyGILState_Release'

The problem seems to have appeared with:

[svn r67802] #3632: the "pyo" macro from gdbinit can now run when the
GIL is released.

Patch by haypo.


diff -r 68d511e1c4bc -r 584e97b40be9 Objects/object.c
--- a/Objects/object.c  Mon Dec 15 22:47:57 2008 +0100
+++ b/Objects/object.c  Mon Dec 15 23:29:14 2008 +0100
@@ -331,8 +331,11 @@
        if (op == NULL)
                fprintf(stderr, "NULL\n");
        else {
+               PyGILState_STATE gil;
                fprintf(stderr, "object  : ");
+               gil = PyGILState_Ensure();
                (void)PyObject_Print(op, stderr, 0);
+               PyGILState_Release(gil);
                /* XXX(twouters) cast refcount to long until %zd is
                   universally available */
                fprintf(stderr, "\n"

Oops, here is a fix for my regression.

Why is PyGILState_Ensure() defined in Include/pystate.h in there is not
thread? PyGILState_Ensure() implementation is conditional (in
Python/pystate.c). Here is a patch to make the definition optional.

Another patch to fix _sqlite without thread support.

_multiprocessing modules doesn't compile but I don't know how to fix it:
 - conn_poll() has a _save argument, but the argument is not used in
both conn_poll() implementations (pipe_connection.c and socket_connection.c)
 - Modules/_multiprocessing/semaphore.c contains a lot of functions and
macros for semaphore managment but it looks like thread support is
required. Eg. compilation fails on a missing symbol: sem_unlink(). The
function sem_unlink() is defined in system <semaphore.h> and requires
-lrt or -lpthread compiler flag.

Here is a patch to remove the unused _save argument of conn_poll()
function from the _multiprocessing mode. It fixes one of the compilation
problem without thread support.

There is already a separate issue for multiprocessing compilation: #3807

Victor - there is already another bug and a pending patchbto fix  
multiprocessing when thread support is enabled. Please do not focus on  
that.

@pitou and @jnoller: Ok ok, fine, I will check #3807.

I've committed the fix for issue 3807 to resolve the mp issues.

Python trunk is still broken --without-threads. The multiprocessing 
issue (#3807) is now closed, so can someone review (or apply?) my 
patches?

Updated and completed patch for _sqlite module (python trunk).

New patch _tkinter_nothread.patch: fix gcc warnings in _tkinter.

Victor, I have changed your tkinter patch a bit and applied on r70641.

The issue is marking only python 2.7 right now, aren't these changes
supposed to be applied 26-maint, py3k and 30-maint too ?

gpolo> Victor, I have changed your tkinter patch a bit and applied on r70641.

Ok, thanks.

gpolo> The issue is marking only python 2.7 right now, aren't these changes
gpolo> supposed to be applied 26-maint, py3k and 30-maint too ?

Since it only fixes warnings, we don't have to "fix" *-maint versions. But I 
would like to see your fix in py3k (I think that trunk and py3k should be as 
close as possible).

_tkinter patch (r70641) was backported to py3k as r70707. py3k compiles fine without threads.