To build Mussa on OS X as a universal binary obviously requires that all of the dependencies be built as universal binaries.

Qt

Thankfully Qt was quite simple, as there is a "-universal" switch that one needs to pass to the configure script.

Some of the systems used to build mussa have png libraries in the /usr/local/lib directories, so to make redistribution a little simpler, the version qt the OS X binary is linked against uses the qt versions of a number of graphics libraries.

configure --prefix=/usr/local/qt/4.2.3 -qt-libpng -system-zlib -qt-libjpeg -qt-gif -qt-libmng -fast -confirm-license -universal

Redistributing OS X binaries is quite annoying, as OS X pre-links all shared libraries, so unless one installs the Qt frameworks in exactly the same place as the development machine Mussa won't work.

Included in the Mussa source tree is a small python script source:makelib/osxdist.py which will copy the Qt frameworks into the .app bundle and properly bless all of the binaries with install_name_tool.

Boost

Boost unfortunately uses its own unique build system and getting the options right isn't nearly as easy.

To configure boost 1.34.1 to build as universal binary, I ran their configure script which generated a user-config.jam. There I changed using darwin ; to

using darwin : 4.0 : g++-4.0 : 
  <cflags>"-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" 
  <linkflags>"-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386"
; 

To configure boost 1.33.1 as a universal binary with optimization and debugging on I used the following

bjam --with-python-version=2.3 "-sTOOLS=darwin" \
   "-sGXX=g++ -O3 -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" \
   "-sGCC=gcc -O3 -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" \
   "-sBUILD=,-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386"

Python

OS X ships with Python 2.3, however if you have installed a later version of python it is fairly likely that mussa will attempt to build against the later version. (Which can be a problem if you're making a version to redistribute. I used the following settings with ccmake to force using the default system version of python.

  PYTHON_DEBUG_LIBRARY   -F/System/Library/Frameworks -framework Python
  PYTHON_EXECUTABLE      /usr/bin/python2.3                           
  PYTHON_INCLUDE_PATH    /usr/include/python2.3                       
  PYTHON_LIBRARY         -F/System/Library/Frameworks -framework Python

PostgreSQL

Qt has a database layer that can connect to several databases such as sqlite3, postres, and mysql. Since I had a non-universal copy of postgresql installed, Qt detected it and tried to build with it, and then failed when it tried to link the single archtecture library against a fat binary. Because I was stubborn, I upgraded Postgres instead of telling Qt to not include Postgres.

In several places the Postgres make files attempt to construct an .o file out of several other .o files using ld. On OS X ld can only handle single architectures, and developers are supposed to switch to libtool. I didn't want to modify the postgres build system so I wrote another small python script source:makelib/uld that wrapps ld with a little bit of glue to handle the multiple architectures.

With that bit of assitance the following should work.

export CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 
export LD="<path to uld>/uld -arch i386 -arch ppc"
./configure
make

One can't add -arch options to both CFLAGS and LDFLAGS as there are a number of places where the Postgres build system passes both $CFLAGS and $LDFLAGS to gcc which generates a duplicate -arch error message. (In the process breaking configure).