Source: http://blog.ultranurd.net/0000/01/28/compiling-django-with-twitter-support-as-a-mac-os-x-universal-binary/#Python

Files:

  1. MySQL 5.1.30
  2. Python 2.6.1
  3. setuptools 0.6c9-py2.6
  4. MySQL-python 1.2.2
  5. Django 1.0.2-final
  6. simplejson 2.0.7
  7. python-twitter 0.5
  8. mod_python 3.3.1

Python

While 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:

1c1

< #!/usr/bin/python2.3

> #!/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'

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.

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!

cd /usr/local/src/Python-2.6.1/Mac/BuildScript/

./build-installer.py

Depending on your shell configuration, you may need to make changes. In my $PATH /usr/local/bin/ trumps /usr/bin/, and I want to keep the Leopard system install of Python 2.5 in place in /System/Library/ and /usr/bin/. Here’s what I did:
cd /usr/local/bin/

for py in find /Library/Frameworks/Python.framework/Versions/2.6/bin -name py*; do ln -s $py; done;

This creates a symlink in /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 python now, 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.

modpython

Sadly, we end with some pain. Long story short, modpython relies on 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. apxs retrieves useful compiler options, apparently based on the ones used to build your local copy apache… and herein lies the problem. apxs reads those flags from /usr/share/httpd/build/config_vars.mk, and if you inspect that file, you’ll see that there are no CFLAGS or LDFLAGS specified. This is particularly odd, considering that httpd is clearly running as a 64-bit process (according to Activity Monitor), and file reports 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 libtool.

This is probably a terrible idea.

Make a backup of config_vars.mk before adding the four architecture flags to CFLAGS and LDFLAGS on lines 59 and 62:

59c59

< CFLAGS =

> CFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64 62c62

< LDFLAGS =

> LDFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64

If you run apxs -q CFLAGS or apxs -q LDFLAGS, you’ll see these values, instead of empty strings.

Now just run the standard autoconf procedure to build and  install modpython.so in /usr/libexec/apache2/:

cd /usr/local/src/modpython-3.3.1/

./configure

make

cd test

python test.py

cd ..

make

sudo make install