|
Todd Boland
itodd at itodd.org
Fri Sep 24 11:09:09 EDT 2004
I did not attempt to use the Python which came with OS X. I built my own without any problems. just prefix with /usr/local and you are all set. the mac version will be left alone and you'll have a brand new python in /usr/local. If you need step by step instructions, let me know, I'd be glad to help. Todd On Sep 24, 2004, at 1:37 AM, Graham Dumpleton wrote: > 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) > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python > -- Todd Boland Software Engineer Charged Software (508) 887-2885 Facsimile: (978) 264-0058 -- Statement of Confidentiality: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify Todd Boland, at (508) 887-2885 immediately, and destroy all copies of this message and any attachments.
|