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, though by boost 1.36 they've made progress in simplifying building an os x universal binary.
For boost 1.36.0 (which isn't tested as of [,617]) use the following bjam command (After installing bjam and extracting the archive.)
bjam --toolset=darwin architecture=combined link=static
- link=static gives you static libraries which means not having to fix-up the *.dylibs when installed into an app bundle.
- architecture=combined builds fat libraries with both i386 and ppc code.
Problems with boost 1.36
- macosx-version=10.4 was supposed the resulting binary to run on a 10.4 system, unfortunately the serialization library wouldn't link with the 10.4 SDK.
To configure boost 1.34.0 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).