Updated below (08/26/2014).
As you’ve probably noticed, I like to compile things. Package management, although useful, just really doesn’t do it for me. Recently, I had to set up a customized install of PHP on CentOS and was forced to use RPM. Well, the experience was funky to say the least. The basic php install had all compile-ins disabled. I had to root around and find the specific package, such as GD, then RPM it into PHP via an ini directive in /etc/php.d/. This sort of drove me nuts.
Anyway, onto Django. Snow Leopard comes with Python 2.6.1 and Apache 2.2.11. Of course I compiled my own version of Apache, resulting in a 2.2.13 version in /usr/local. I left Python alone. Installing Django was a snap and once again I had to go the bleeding edge route and use the Django trunk as my install, symlinking it into /Library/Python/2.6/site-packages/. This worked just great. Now I needed Apache to serve up my Django framework. I had the choice of mod_python or mod_wsgi and seeing the benefits of mod_wsgi, I went with that (also I’ve had horrible experiences with mod_python in the past).
I downloaded mod_wsgi, and did the following:
# tar -xzvf mod_wsgi-2.6.tar.gz
# cd mod_wsgi-2.6
# ./configure --with-apxs=/usr/local/apache2/bin/apxs
# make install
And it blew up with the following error:
Warning! dlname not found in /usr/local/apache2/modules/ mod_wsgi.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/apache2/modules/mod_wsgi.so
chmod: cannot access `/usr/local/apache2/modules/mod_wsgi.so’: No such file or directory
apxs:Error: Command failed with rc=65536
make: *** [install] Error 1
Great, mod_python nightmares started returning. I did some research and found many people were having problems with mod_wsgi on Snow Leopard. Graham Dumpleton, the maintainer has been very active in helping people out. His main suggesting was to modify the Makefile to have it point to the correct version of Python by modifying the LDFLAGS and LDLIBS. None of these suggestions worked for me, and even Graham seemed baffled as to why it would work on some Snow Leopard systems and not on others. One of his points was that people with a MacPorts build of Python were corrupting the mod_wsgi process as this build is a bit shaky. Without specifying your version of Python during ./configure, the MacPorts libraries would supersede the default install or other compiled versions. I checked an indeed I had a MacPorts Python in /opt/local/. How did that get there? I hate package managers.
But this wasn’t the problem as I could see the correct version of Python in the Makefile. Most of the people having problems had a customized Python build, but I was on the other side with a customized Apache build. So I looked into the difference between my APXS and the default APXS. The only major difference was on line 199:
($httpd = $0) =~ s:support/apxs$:httpd:;
My version did not have that httpd in there and looked like:
($httpd = $0) =~ s:support/apxs$::;
Making this change solved the problem. I’m not sure what I did to get a funky APXS, so if anyone knows I’d love to hear it.
I had some other issues with permissions, paths, and eggs, but they were fairly simple and if you follow the documentation, you can get everything working. I don’t always RTFM.
Hopefully this saves someone else the time and misery of setting up Django using mod_wsgi under Snow Leopard.
So here I am years later, having completely abandoned apache for nginx, and somehow get stuck with getting graphite up and running. After the fun of py2cairo, I just wanted to keep to the script as much as possible so I went with apache httpd. I ran into my good friend, the apxs:Error: Command failed with rc=65536 error above.
I’ve seen this before. I google it and find this page but the missing httpd doesn’t do anything. Uh oh. Looks like another person or two has had the same problem so I follow their advice “rebuild apache without –enable-module or –enable-shared”, and bam, it works.
If I have time to dive into the details of why, I’ll update this post again. Here is the helpful thread (that references this page).