Yes, this new code is something I commited on the 29/12/2004 (I used the 
"blame" function of TortoiseSVN for that). It was a patch by Graham to fix 
MODPYTHON-2 <http://issues.apache.org/jira/browse/MODPYTHON-2>.

The problem is not in the patch, but rather in the fact that APR seems 
configured without the thread support while Python is configured with thread
 
support. mod_python.c assumes that is WITH_THREAD is defined, then the APR 
mutex functions are available, which is wrong. Maybe we should test for 
APR_HAS_THREADS instead ? In that case, won't this cause any problems on 
threaded platforms ?

I don't know if this is a problem specific to minotaur or to all version of 
FreeBSD. I'm currently downloading the ISOs of FreeBSD and I'll try using 
QEMU to run a FreeBSD setup on my computer, but that will be long and 
troublesome. If someone has more clue on this issue, feel free to tell us 
.

Regards,
Nicolas

2005/9/10, Jim Gallacher <jg.lists@sympatico.ca>:
> I'm stubling around in the dark here, but maybe this will create a spark
> of an idea. I took a diff of mod_python.c from 3.1.4 and 3.2.1b and
> isolated the lines which correspond to the compilation error.
> 
> Compiler messages
> -----------------
> 
> mod_python.c:34: error: syntax error before '*' token
> mod_python.c:34: warning: type defaults to `int' in declaration of
> `interpreters_lock'
> mod_python.c:34: warning: data definition has no type or storage class
> mod_python.c: In function `get_interpreter':
> mod_python.c:131: warning: implicit declaration of function
> `apr_thread_mutex_lock'
> mod_python.c:161: warning: implicit declaration of function
> `apr_thread_mutex_unlock'
> mod_python.c: In function `python_init':
> mod_python.c:517: warning: implicit declaration of function
> `apr_thread_mutex_create'
> mod_python.c:517: error: `APR_THREAD_MUTEX_UNNESTED' undeclared (first
> use in this function)
> 
> 
> Diff output
> -----------
> I've only copied the diff chunks which correspond to the complier errors
> mentioned above.
> 
> --- mod_python-3.1.4/src/mod_python.c Sat Jan 29 13:25:28 2005
> +++ mod_python-3.2.1b/src/mod_python.c Tue Sep 6 17:11:03 2005
> @@ -31,6 +31,8 @@
> * (In a Python dictionary) */
> static PyObject * interpreters = NULL;
> 
> +static apr_thread_mutex_t* interpreters_lock = 0;
> +
> apr_pool_t *child_init_pool = NULL;
> 
> ... snip ...
> 
> @@ -124,11 +128,15 @@
> name = MAIN_INTERPRETER;
> 
> #ifdef WITH_THREAD
> +  apr_thread_mutex_lock(interpreters_lock)
;
> PyEval_AcquireLock();
> #endif
> 
> ... snip ...
> 
> @@ -149,6 +158,7 @@
> 
> #ifdef WITH_THREAD
> PyEval_ReleaseLock();
> +  apr_thread_mutex_unlock(interpreters_loc
k);
> #endif
> 
> ... snip ...
> 
> @@ -490,13 +506,15 @@
> }
> 
> /* initialize global Python interpreter if necessary */
> - if (! Py_IsInitialized())
> + if (initialized == 0 || !Py_IsInitialized())
> {
> -
> + initialized = 1;
> +
> /* initialze the interpreter */
> Py_Initialize();
> 
> #ifdef WITH_THREAD
> +
> apr_thread_mutex_create(& interpreters_lock,APR_THREAD_MUTEX_UNNES
TED,p);
> /* create and acquire the interpreter lock */
> PyEval_InitThreads();
> #endif
> 
> So it would seem that the code causing the compile problems is new for 3.2
.
> 
> I also notice that in apr_arch_thread_mutex.h the typedef for
> apr_thread_mutex_t is wrapped by #if APR_HAS_THREADS / #endif.
> 
> Looking at the apache source in srclib/apr/locks/unix/thread_mutex.c,
> everything is also enclosed by #if APR_HAS_THREADS / #endif.
> eg, apr_thread_mutex_create, apr_thread_mutex_lock and
> apr_thread_mutex_unlock.
> 
> Hopefully this will give someone a clue as to what may be going on here
> with FreeBSD.
> 
> Regards,
> Jim
>

[ Post a follow-up to this message ]