|
Graham Dumpleton
grahamd at dscpl.com.au
Fri Sep 24 00:37:14 EDT 2004
A while back, I posted as to how I managed to get standard Apache 1.3 and Python 2.3 as supplied with the Mac OS X (10.3.5) operating system, working with the older mod_python 2.7.10. Specifically, a hack was required because the Python framework library as supplied with the Mac was appearing to already be initialised when mod_python was initialised, even though it hadn't. The original email and the hack made is attached below. Anyway, I have now installed Apache 2.0.51 and mod_python 3.1.3 and have run up against the exact same problem. Remembering, this is with the version of Python that comes with the operating system, ie., Python 2.3. I even rebuilt my box from scratch recently so it is a relatively fresh install of Mac OS X. My question is whether anyone running Apache 2.0 and mod_python 3.1.3 on Mac OS X, has done so by using the version of Python that comes with the operating system? The various posts I have seen talk about having downloaded the more recent Python 2.3.4 and compiling it from scratch. Ie., not using that supplied with the operating system. If this is the case, and everyone has been building a new version of Python, it suggests that the problem I am seeing is generic to Python 2.3 that comes with the Mac and applies to any version of mod_python. Alternatively, it comes about because of underlying problems with how the loadable object for mod_python is being created on the Mac. On Aug 04 21:37, Graham Dumpleton <grahamd at dscpl.com.au> wrote: > > Subject: Re: [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) > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python > > -- Graham Dumpleton (grahamd at dscpl.com.au)
|