Bringing accountability and transparency to the Donation industry, we offer the tools to track your generosity from your hands, directly through to the end recipient, with nothing cut out for miscellaneous fees. Together, we can avoid the Donation Black Hole problem perpetuated by many charities. You will not need to wonder about where your money goes, we will show you every step of the way through a trackable, database. And more importantly, you can interact directly with those whose lives you have impacted, and follow their progress.
- MySQL 5.1.30
- Python 2.6.1
- setuptools 0.6c9-py2.6
- MySQL-python 1.2.2
- Django 1.0.2-final
- simplejson 2.0.7
- python-twitter 0.5
- mod_python 3.3.1
PythonWhile python.org provides a nice OS X Installer package for 2.6.1, it is compiled as a 32-bit “fat” binary, which doesn’t help us address the Universality problem. We’ll use their script for generating a package as well as installing the framework directly, after some minor changes, courtesy this mailing list post by Ned Deily.
If you’re feeling particularly trustworthy, you can download the disk image containing the Installer package that I built from my website. If not, you can make the changes yourself. Either way, Python.framework will be installed in /Library/Frameworks/.
In the Python 2.6.1 source directory, open the file
Mac/BuildScript/build-installer.py in your favorite editor, and make the following changes on lines 1, 65, 68, 71, 633, and 1020:
You’ll note that some of the changes migrate this script to 10.5 (the hashbang path to Python, the deployment target and SDK version), and some of the changes add support for a Universal binary (adding to the architecture list. It’s possible that some of these changes will be fixed in a future source release of Python 2.6, but I’d guess that most efforts are focused on Python 3.0 at this point.
> #!/usr/bin/python 65c65
< DEPSRC = os.path.expanduser('~/Universal/other-sources')
> #DEPSRC = os.path.expanduser('~/Universal/other-sources') 68c68
< SDKPATH = "/Developer/SDKs/MacOSX10.4u.sdk"
> SDKPATH = "/Developer/SDKs/MacOSX10.5.sdk" 71c71
< ARCHLIST = ('i386', 'ppc',)
> ARCHLIST = ('i386', 'ppc', 'x86_64', 'ppc64') 633c633
< runCommand("%s -C --enable-framework --enable-universalsdk=%s LDFLAGS='-g -L%s/libraries/usr/local/lib' OPT='-g -O3 -I%s/libraries/usr/local/include' 2>&1"%(
> runCommand("%s -C --enable-framework --enable-universalsdk=%s --with-universal-archs=all LDFLAGS='-g -L%s/libraries/usr/local/lib' OPT='-g -O3 -I%s/libraries/usr/local/include' 2>&1"%( 1020c1020
< os.environ['MACOSXDEPLOYMENTTARGET'] = '10.3'
> os.environ['MACOSXDEPLOYMENTTARGET'] = '10.5'
Once you’ve made the changes, just run the script. You need to be in the BuildScript subdirectory, unless you want to change some of the tmp paths the script uses. This script will do everything, build the framework, download and build any dependencies, install the framework, and generate a disk image. Just sit back and wait!
Depending on your shell configuration, you may need to make changes. In my
/usr/bin/, and I want to keep the Leopard system install of Python 2.5 in place in
/usr/bin/. Here’s what I did:
This creates a symlink in
for py in
find /Library/Frameworks/Python.framework/Versions/2.6/bin -name py*; do ln -s $py; done;
/usr/local/bin/for each of the various just-build Python binaries inside the framework (you’ll not that this is equivalent to the system install). If you run
which pythonnow, it should return
/usr/local/bin/python. If not, adjust your $PATH as needed in your shell configuration file. This is beyond the scope of this post.
modpythonSadly, we end with some pain. Long story short,
apxs(the APache eXtenSion tool, best abbreviation ever) to configure its build, and does not obey any amount of environment variable manipulation to pass in multiple architectures.
apxsretrieves useful compiler options, apparently based on the ones used to build your local copy apache… and herein lies the problem.
apxsreads those flags from
/usr/share/httpd/build/config_vars.mk, and if you inspect that file, you’ll see that there are no
LDFLAGSspecified. This is particularly odd, considering that
httpdis clearly running as a 64-bit process (according to Activity Monitor), and
filereports that all of my other shared objects in
/usr/libexec/apache2/are Universal binaries.
This next bit is my idea, since I couldn’t find any suggestions by googling around. I know perl, so I just read the
apxs script to figure out what it was doing, and how it was passing arguments to
This is probably a terrible idea.
Make a backup of
config_vars.mk before adding the four architecture flags to
LDFLAGS on lines 59 and 62:
If you run
< CFLAGS =
> CFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64 62c62
< LDFLAGS =
> LDFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64
apxs -q CFLAGSor
apxs -q LDFLAGS, you’ll see these values, instead of empty strings.
Now just run the standard autoconf procedure to build and install
sudo make install