[mod_python] Status of Mac OS X / Apache 1.3 / mod_python 2.7.10.

On Aug 04 15:26, Justin Ryan <jryan at qutang.net> wrote:
>
> Subject: Re: [mod_python] Status of Mac OS X / Apache 1.3 / mod_python 2.7.10.
>
> Be careful when playing with the file/directory/link/whateva that is 
> /System/Library/Frameworks/Python.Framework.  I ran into some wierdness 
> trying to change this into a symlink and move it around (i.e. change it 
> back and forth from pointing to Apple's python and my own).
> 
> Also, take care when using the 'python' command after installing your 
> own framework build.  It's kind of a pain to get a framework build to 
> stick python, pythonw, etc.. in /usr/bin - all of my stuff was in 
> /usr/local/bin, even though I passed --prefix=/usr to the configure 
> script.

I would agree and why I didn't want to go down the path of having to replace
the standard version of Python on MacOSX with a newer version to get mod_python
to work. Similarly, I didn't want to be replacing their version of Apache.

Anyway, listed below is the changes I had to make to get it to build and work
on MacOSX (10.3.3) with the standard Python (2.3) and Apache (1.3) that come
with the operating system.

First off, after running configure, change "src/Makefile" and replace:

  /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/libpython2.3.a

with:

  -framework Python

in LIBS variable.

Second, in the same makefile, change CFLAGS and add in:

  -DEAPI

as a compiler option.

This will allow mod_python to build, but the result will crash.

Final step is to modify src/mod_python.c. The diff is below. There are
more comments after that diff as to why the original code is wrong anyway.


*** mod_python.c.dist   Tue May 29 06:00:41 2001
--- mod_python.c        Thu Aug  5 13:21:22 2004
***************
*** 260,265 ****
--- 260,268 ----
  
      char buff[255];
  
+     /* fudge for Mac OS X with Apache 1.3 where Py_IsInitialized() broke */
+     static int initialized = 0;
+ 
      /* pool given to us in ChildInit. We use it for 
         server.register_cleanup() */
      pool *child_init_pool = NULL;
***************
*** 272,279 ****
      ap_add_version_component(buff);
  
      /* initialize global Python interpreter if necessary */
!     if (! Py_IsInitialized()) 
      {
  
        /* initialze the interpreter */
        Py_Initialize();
--- 275,283 ----
      ap_add_version_component(buff);
  
      /* initialize global Python interpreter if necessary */
!     if (initialized == 0 || ! Py_IsInitialized())
      {
+         initialized = 1;
  
        /* initialze the interpreter */
        Py_Initialize();


The problem on MacOSX is that Py_IsInitialized() is returning true on the
first time it is called even though Python hadn't up until that point actually
been initialised. This means initialisation is skipped and the first time
something tries to use Python methods later, it crashes.

To my mind the use of Py_IsInitialized() is partly bogus anyway. This is
because if someone did come up with a different apache module which
also tried to use Python and it got loaded first and called Py_Initialize(),
it would mean when mod_python got loaded it would skip initialisation
and wouldn't initialise as a result the "interpreters" dictionary nor would
it necessarily initialise threading if the other module didn't do it.

Thus, even though people might reckon that this patch may only be
relevant to the MacOSX problem I have, I would disagree, because I would
say the code is wrong anyway.

As a demonstration, you might modify the code and add an extra call to
Py_Initialize() just prior to the "if" statement where Py_IsInitialized() is
called as if it was done somewhere else. Do this and mod_python should
by observation break since "interpreters" will never get set as described above.

--
Graham Dumpleton (grahamd at dscpl.com.au)