OK, first of all the interpreters_lock mutex only needs to be defined if we have threads :
Index: src/mod_python.c =================================================================== --- src/mod_python.c (revision 280013) +++ src/mod_python.c (working copy) @@ -31,7 +31,9 @@ * (In a Python dictionary) */ static PyObject * interpreters = NULL; +#ifdef WITH_THREAD static apr_thread_mutex_t* interpreters_lock = 0; +#endif apr_pool_t *child_init_pool = NULL; Then, it looks like the apr_thread_mutex functions are not defined on minotaur. Having a look at apr_thread_mutex.h, I saw that on line 35 : #if APR_HAS_THREADS || defined(DOXYGEN) Would it be possible that apache was compiled without threads on minotaur ? What I don't understand is why WITH_THREAD is defined, in that case... Regards, Nicolas 2005/9/10, Jim Gallacher <[EMAIL PROTECTED]>: > Nicolas Lehuen wrote: > > I've tried to build 3.1.4 from the tarball on minotaur and of course > > it works. Could it be possible that the recent changes in the > > configure script cause the problem ? > > I don't think so, but I ran a simple test on minotaur just to make sure. > > I copied configure.in and dist/setup.py.in from 3.1.4 to 3.2.1b and > regenerated configure with autoconf259. Compilation still fails at the > same point with the same error. > > If only it had been that simple. :-( > > Jim > > > Regards, > > > > Nicolas > > > > 2005/9/10, Jim Gallacher <[EMAIL PROTECTED]>: > > > >>I thought I'd it a shot on minotaur as well. > >> > >>Poking around a bit reveals that the default apache is indeed 1.3. It > >>looks like there might be a viable apache2 hiding in > >>/usr/local/apache2-install/www.apache.org/current. > >> > >>eg ./configure > >>--with-apxs=/usr/local/apache2-install/www.apache.org/current/apxs > >> > >>Unfortunately, I'm getting the same errors as Grisha reported starting with: > >>mod_python.c:34: error: syntax error before '*' token > >> > >>Regards, > >>Jim > >> > >>Nicolas Lehuen wrote: > >> > >>>I tried to build it under minotaur as well, but "./configure" only > >>>finds a 1.3.33 version of Apache, so I can't go further. I can't help > >>>much here since I'm not used to FreeBSD... > >>> > >>>Regards, > >>>Nicolas > >>> > >>>2005/9/9, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>: > >>> > >>> > >>>>Just tried compiling it on minotaur and I get the same error. minotaur is > >>>>FreeBSD 5.4, so it looks like we have a -1. I don't know how much time > >>>>I'll have this weekend, so I might or might not look into the cause of > >>>>this - but anyone else with access to a FreeBSD box, you're more than > >>>>welcome to dig in... :-) > >>>> > >>>>Grisha > >>>> > >>>> > >>>>On Fri, 9 Sep 2005, Jim Gallacher wrote: > >>>> > >>>> > >>>> > >>>>>Gregory (Grisha) Trubetskoy wrote: > >>>>> > >>>>> > >>>>>>Don't know about versions, but I'd _really_ like to see a FreeBSD +1 at > >>>>>>this point :-) Graham - don't you have FreeBSD access somewhere? > >>>>> > >>>>>If Graham can't help out maybe we could recruit a volunteer on the > >>>>>mod_python > >>>>>list? > >>>>> > >>>>> > >>>>> > >>>>>>On the versioning discussion - I don't like 4.0, I think 3.3 should be > >>>>>>the > >>>>>>next version after 3.2.x. As far as even/odd stable/unstable - the Linux > >>>>>>kernel folks have abandoned it because it didn't work for them. The > >>>>>>fallacy is that you cannot know ahead of time what is stable and what is > >>>>>>not. > >>>>>> > >>>>>>My preference is to just follow versions incrementally, and making it > >>>>>>known which version is stable or not independently of the version > >>>>>>number, > >>>>>>which is what the HTTPD folks have been doing. > >>>>> > >>>>>I can't get worked up one way or another wrt to a version numbering > >>>>>scheme, > >>>>>as long as we release *something*. ;) > >>>>> > >>>>>Regards, > >>>>>Jim > >>>>> > >>>> > >> > > > >
