[mod_python] Mac OS X / Apache 2.0 / mod_python 3.1.3 / Python 2.3.

Mark McClain mark at gsoa.net
Fri Sep 24 15:12:18 EDT 2004


I have built mod_python on 10.3.[2,3,4,5] for multiple machines in our  
office without problems.  I use the version of python shipped with OS X  
and apache 2.0 which I compiled.

I did run into some weirdness with the gcc depending on the method for  
installing Xcode.  That issue was because apple changed the libraries  
that the Xcode installed versus the OS installation provided; however,  
that problem would present itself at compile time not runtime.

I have another clean machine that I'll try it out on this weekend.

mark

On Sep 24, 2004, at 7:28 AM, Graham Dumpleton wrote:

> The problem I was having with both Apache 1.3/2.0 and corresponding  
> mod_python
> for those versions loaded, was that as soon as Apache was started, all  
> the forked
> processes would crash.
>
> [Fri Sep 24 15:06:01 2004] [notice] SIGHUP received.  Attempting to  
> restart
> [Fri Sep 24 15:06:02 2004] [notice] Apache/2.0.51 (Unix) configured --  
> resuming normal operations
> [Fri Sep 24 15:06:10 2004] [notice] child pid 15196 exit signal Bus  
> error (10)
> [Fri Sep 24 15:06:10 2004] [notice] child pid 15194 exit signal Bus  
> error (10)
> [Fri Sep 24 15:06:10 2004] [notice] child pid 15192 exit signal Bus  
> error (10)
> [Fri Sep 24 15:06:10 2004] [notice] child pid 15190 exit signal Bus  
> error (10)
> [Fri Sep 24 15:06:10 2004] [notice] child pid 15188 exit signal Bus  
> error (10)
>
> Make the mod_python.c file fix I described and it all works fine.
>
> Thus, has nothing to do with command line execution of Python.
>
> On 24/09/2004, at 9:13 PM, John Raines wrote:
>
>> There's a Macpython IDE that would run a lot of python code and  
>> necessarily initialize some things, I think. Is that really the issue  
>> or are you dealing with python itself from the command line? I'm  
>> still trying to get things working myself and I did download a new  
>> version of python although I think I'm one version behind you on both  
>> Apache and python.
>> On Sep 24, 2004, at 12: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
>>>
>>
>> _______________________________________________
>> Mod_python mailing list
>> Mod_python at modpython.org
>> http://mailman.modpython.org/mailman/listinfo/mod_python
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>



More information about the Mod_python mailing list