mod_wsgi, Snow Leopard, and Python 3.1
Joe
I downloaded the latest version of the mod_wsgi source, configured
it, modified the make file to use python 3.1 instead of the Macintosh
default of 2.6.1 by changing the path, compiled it, installed it,
modified the httpd.conf file, stop and started apache, and ran into a
problem. When I have this line
LoadModule wsgi_module libexec/apache2/mod_wsgi.so
in the httpd.conf file I get
[Mon Feb 01 15:31:11 2010] [notice] caught SIGTERM, shutting down
When I comment it out, the problem goes away. Thus I have to assume
something is wrong, but I'm not certain how to resolve the issue. Any
troubleshooting ideas?
Thanks,
Joe
Graham Dumpleton
> Hi All,
>
> I downloaded the latest version of the mod_wsgi source, configured
> it, modified the make file to use python 3.1 instead of the Macintosh
> default of 2.6.1 by changing the path, compiled it, installed it,
> modified the httpd.conf file, stop and started apache, and ran into a
> problem. When I have this line
>
> LoadModule wsgi_module libexec/apache2/mod_wsgi.so
>
> in the httpd.conf file I get
>
> [Mon Feb 01 15:31:11 2010] [notice] caught SIGTERM, shutting down
That is a normal message that you will see Apache output whenever you
perform a stop, and possibly even a restart of Apache. It has nothing
to do with mod_wsgi.
Graham
> When I comment it out, the problem goes away. Thus I have to assume
> something is wrong, but I'm not certain how to resolve the issue. Any
> troubleshooting ideas?
>
> Thanks,
> Joe
>
> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>
Joe Hughes
The issue is that if the module is in the list to load, apache won't start. When I do a ps -ef with the module commented out and do an apachectl restart, I get multiple httpd processes. I don't get any httpd processes when it is uncommented.
Also know anything about Solaris issues with mod_wsgi? I get
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536
.
make: *** [mod_wsgi.la] Error 1
From what I've read on the web it is an ld issue. Have you seen this? Solaris 8, SPARC, and whatever else you need.
Thanks,
Joe
Graham Dumpleton
> Hi Graham,
>
> The issue is that if the module is in the list to load, apache won't start. When I do a ps -ef with the module commented out and do an apachectl restart, I get multiple httpd processes. I don't get any httpd processes when it is uncommented.
Run:
apachectl -t
That should show you the error message about what undefined symbols
there are when loading module and which is causing Apache to fail to
start.
Post the complete error messages here.
Then also read:
http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
so you get a background about what the problems are.
In short, you likely aren't using Apple supplied Apache and Python and
instead using MacPorts, fink or HomeBrew, all of which are a PITA
because the Python isn't usually compiled properly to allow linking
into an embedded system.
So, also indicate whose Apache and Python you are using, where they
are installed and what command line you used when you ran configure
for mod_wsgi.
> Also know anything about Solaris issues with mod_wsgi? I get
>
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status
> apxs:Error: Command failed with rc=65536
> .
> make: *** [mod_wsgi.la] Error 1
>
> From what I've read on the web it is an ld issue. Have you seen this? Solaris 8, SPARC, and whatever else you need.
Read:
http://code.google.com/p/modwsgi/wiki/InstallationOnSolaris
Same issue, same solution.
Graham
Joe Hughes
I was assigned a Mac Mini Server to do the development on so let me see if I can answer all your questions. Here is the sequence
1. Downloaded latest Development Tools from Apple
2. Downloaded latest Python source from Python.org
3. Tried to configure but found an issue
4. Modified configure so it didn't have ppc64 as an architecture in the all option
5. Configured with no errors
./configure --prefix=/usr/local/python-3.1.1 \
--enable-framework=/usr/local/python3.1.1/frameworks \
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
--with-universal-archs=all
6. Make with no errors
7. Make install with no errors
8. Linked python3.1.1 binary to /usr/local/bin/python3
9. Downloaded latest mod_wsgi
10. Configured with no errors
./configure --with-python=/usr/local/bin/python3
11. Make with no errors
12. Make install with no errors
13. Added
LoadModule wsgi_module libexec/apache2/mod_wsgi.so
to httpd.conf
14. Checked apachectl -t and no errors
15. Stopped and then started Apache
16. Loaded the files onto the mac server
17. Used the wrong URL which gave me an error with Apache/2.2.13 (Unix) mod_wsgi/3.1 Python/3.1.1
which tells me that mod_wsgi is working
18. Got the right URL and got what I was expecting
Thus except for the python configure bug (The Mac Mini reports ppc, i386, and x86_64 for httpd) everything looks good.
Thanks,
Joe
Graham Dumpleton
> Hi Graham,
>
> I was assigned a Mac Mini Server to do the development on so let me see if I can answer all your questions. Here is the sequence
>
> 1. Downloaded latest Development Tools from Apple
Why not just use the version of Apache supplied with the operating system?
> 2. Downloaded latest Python source from Python.org
Why not just use the version of Python supplied with the operating system?
> 3. Tried to configure but found an issue
What issue? Show the exact output and error messages you were presented with.
> 4. Modified configure so it didn't have ppc64 as an architecture in the all option
> 5. Configured with no errors
>
> ./configure --prefix=/usr/local/python-3.1.1 \
> --enable-framework=/usr/local/python3.1.1/frameworks \
> --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
> --with-universal-archs=all
This is wrong, as documented in:
http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
on Snow Leopard you should have used:
./configure --prefix=/usr/local/python-3.1.1 \
--enable-framework=/usr/local/python3.1.1/frameworks \
--enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
--with-universal-archs=3-way
Note how '3-way' is used instead of 'all'.
If you had done the right thing, you probably wouldn't have needed to
hack Python configure script.
> 6. Make with no errors
> 7. Make install with no errors
> 8. Linked python3.1.1 binary to /usr/local/bin/python3
> 9. Downloaded latest mod_wsgi
> 10. Configured with no errors
>
> ./configure --with-python=/usr/local/bin/python3
>
> 11. Make with no errors
> 12. Make install with no errors
> 13. Added
>
> LoadModule wsgi_module libexec/apache2/mod_wsgi.so
>
> to httpd.conf
> 14. Checked apachectl -t and no errors
> 15. Stopped and then started Apache
> 16. Loaded the files onto the mac server
> 17. Used the wrong URL which gave me an error with Apache/2.2.13 (Unix) mod_wsgi/3.1 Python/3.1.1
> which tells me that mod_wsgi is working
> 18. Got the right URL and got what I was expecting
>
> Thus except for the python configure bug (The Mac Mini reports ppc, i386, and x86_64 for httpd) everything looks good.
So, I take it that it is now working okay and you didn't actually
investigate the reason for the original problem? That is, run
'apachectl -t' for original failing installation so could see if was a
runtime symbol lookup problem as expected it may be based on limited
information supplied.
Graham
Joe Hughes
See my comments below.
Joe
On Feb 4, 2010, at 7:42 PM, Graham Dumpleton wrote:
> On 5 February 2010 07:08, Joe Hughes <jwhug...@gmail.com> wrote:
>> Hi Graham,
>>
>> I was assigned a Mac Mini Server to do the development on so let me see if I can answer all your questions. Here is the sequence
>>
>> 1. Downloaded latest Development Tools from Apple
>
> Why not just use the version of Apache supplied with the operating system?
I did. I downloaded the Development Tools which as far as I know include gcc and other tools, but not Apache.
>
>> 2. Downloaded latest Python source from Python.org
>
> Why not just use the version of Python supplied with the operating system?
I want to use Python3 instead of 2.6. Python is a new language for me and I like looking forward.
>
>> 3. Tried to configure but found an issue
>
> What issue? Show the exact output and error messages you were presented with.
Below is the configuration. I got
checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t)
See `config.log` for more details.
A little research later I found that if I ran this command
gcc -o conftest -g -O2 -arch i386 -arch ppc -arch x86_64 -arch ppc64 -isysroot / conftest.c
I got
ld: warning: in //usr/lib/crt1.10.5.o, missing required architecture ppc64 in file
ld: warning: in //usr/lib/libSystemStubs.a, missing required architecture ppc64 in file
ld: warning: in //usr/lib/libSystem.dylib, missing required architecture ppc64 in file
Undefined symbols for architecture ppc64:
"_fclose", referenced from:
_main in ccj5PURu.o
"_fopen", referenced from:
_main in ccj5PURu.o
"_ferror", referenced from:
_main in ccj5PURu.o
ld: symbol(s) not for for architecture ppc64
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/dN/dN-6jI8kGjKNFFJ-eHeW1k+++TI/-Tmp-//ccizIo*z.out (No such file or directory)
When I take out the -arch ppc64 I don't have the problem. When I do a
file /usr/sbin/httpd
I get
/usr/sbin/httpd: Mach-O universal binary with 3 architectures
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86-64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc
This is why I removed the ppc64 from the configure for the all option.
>
>> 4. Modified configure so it didn't have ppc64 as an architecture in the all option
>> 5. Configured with no errors
>>
>> ./configure --prefix=/usr/local/python-3.1.1 \
>> --enable-framework=/usr/local/python3.1.1/frameworks \
>> --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
>> --with-universal-archs=all
>
> This is wrong, as documented in:
>
> http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX
>
> on Snow Leopard you should have used:
>
> ./configure --prefix=/usr/local/python-3.1.1 \
> --enable-framework=/usr/local/python3.1.1/frameworks \
> --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.6 \
> --with-universal-archs=3-way
>
> Note how '3-way' is used instead of 'all'.
>
> If you had done the right thing, you probably wouldn't have needed to
> hack Python configure script.
I tried --with-universal-archs=3-way and got an invalid option error. I did the ./configure --help and I got 32-bit, 64-bit or all as options.
>
>> 6. Make with no errors
>> 7. Make install with no errors
>> 8. Linked python3.1.1 binary to /usr/local/bin/python3
>> 9. Downloaded latest mod_wsgi
>> 10. Configured with no errors
>>
>> ./configure --with-python=/usr/local/bin/python3
>>
>> 11. Make with no errors
>> 12. Make install with no errors
>> 13. Added
>>
>> LoadModule wsgi_module libexec/apache2/mod_wsgi.so
>>
>> to httpd.conf
>> 14. Checked apachectl -t and no errors
>> 15. Stopped and then started Apache
>> 16. Loaded the files onto the mac server
>> 17. Used the wrong URL which gave me an error with Apache/2.2.13 (Unix) mod_wsgi/3.1 Python/3.1.1
>> which tells me that mod_wsgi is working
>> 18. Got the right URL and got what I was expecting
>>
>> Thus except for the python configure bug (The Mac Mini reports ppc, i386, and x86_64 for httpd) everything looks good.
>
> So, I take it that it is now working okay and you didn't actually
> investigate the reason for the original problem? That is, run
> 'apachectl -t' for original failing installation so could see if was a
> runtime symbol lookup problem as expected it may be based on limited
> information supplied.
It is working on the Mac Mini Server. On my personal mac I still have the issue. This is the error I get from apachectl -t
httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf: Cannot load /usr/libexec/apache2/mod_wsgi.so into server: dlopen(/usr/libexec/apache2/mod_wsgi.so, 10): Symbol not found: _PyBool_Type\n Referenced from: /usr/libexec/apache2/mod_wsgi.so\n Expected in: flat namespace\n in /usr/libexec/apache2/mod_wsgi.so
>
> Graham
Graham Dumpleton
> Hi Graham,
>
> See my comments below.
>
> Joe
>
> On Feb 4, 2010, at 7:42 PM, Graham Dumpleton wrote:
>
>> On 5 February 2010 07:08, Joe Hughes <jwhug...@gmail.com> wrote:
>>> Hi Graham,
>>>
>>> I was assigned a Mac Mini Server to do the development on so let me see if I can answer all your questions. Here is the sequence
>>>
>>> 1. Downloaded latest Development Tools from Apple
>>
>> Why not just use the version of Apache supplied with the operating system?
>
> I did. I downloaded the Development Tools which as far as I know include gcc and other tools, but not Apache.
Sorry, I read that as Apache rather than Apple.
>>> 2. Downloaded latest Python source from Python.org
>>
>> Why not just use the version of Python supplied with the operating system?
>
> I want to use Python3 instead of 2.6. Python is a new language for me and I like looking forward.
Fair enough.
Crap, I hate how Python keeps changing stuff like this.
Tthe option is in Python 2.6 I have and not Python 3.1, yet is in
trunk for Python 3.2.
So, you are right and possibly removing it manually from configure
script may be required for most recent Snow Leopard/XCode versions.
Which suggests you are using one of the various odd Python
versions/installations which isn't encoding stuff in framework
properly.
When running configure on this box for mod_wsgi, try using the option:
--disable-framework
This will cause mod_wsgi to link using -L/-l instead of -F/-framework options.
In most cases gets around the problem.
Graham