Compilation on Mac OS X
This document attempts to describe how to build Stellarium from sources on MacOSX. This process ought to improve over time. The set of instructions was written for the 0.10.4 release and using an Intel machine with Leopard (10.5). The process has to be validated for other versions.
Prepare Mac OS X to build Stellarium
You need a machine with MacOS X 10.4 (latest version 10.4.11) or later
- Install the latest version of Apple's Developer Tools: http://developer.apple.com/technology/xcode.html
- Install the latest version of cmake: http://www.cmake.org/cmake/resources/software.html
- Install the latest version of Qt: Framework from the dmg (4.6.2 at the time these instructions were written) http://qt.nokia.com/downloads
- Install macports: http://www.macports.org/install.php
- Install subversion making use of macports:
$ sudo port install subversion
For MacOSX there are two different versions of Qt:
- Carbon version: Default download and recommended option. It works for MacOS X 10.5/4/3, and both Intel and PPC architectures. Install this one if you want to create universal binaries
- Cocoa version: Exclusively for MacOSX 10.6 and Intel. You can use this if you aren't going to create universal binaries.
Compiling dependencies to build an universal binary
We have to compile the dependencies with special flags to be able to generate an universal binary. If you don't intend to create an universal package you can skip this and going to the next section: #Building stellarium itself
In case you are compiling in a Leopard or Snow Leopard machine you have to recompile stellarium dependencies making use of the oldest system libraries (in our case those in 10.4 aka Tiger). We need the following compilation flags:
a. We want to generate a single binary for both intel and ppc architectures so:
-arch i386 -arch ppc
b. We want to link with the old framework and system libraries:
-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/ (Not sure if this is really needed)
- Libiconv: It's important to compile libiconv in the first place because gettext depends on it. Get the latest release from here: http://www.gnu.org/software/libiconv/ Uncompress the file in your favorite directory and configure and compile like this:
$ ./configure --prefix=/usr CFLAGS='-arch i386 -arch ppc -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/' $ make $ make install
- Gettext: Get the latest release from here: http://www.gnu.org/software/gettext/ . Uncompress the file in your favorite directory and configure and compile like this:
$ ./configure CFLAGS='-arch i386 -arch ppc -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/' $ make $ make install
At the moment of writing these steps 4.6.2 is the latest version of Qt. Trolltech provides support from MacOS 10.4 to 10.6 so our binaries will be constrained by this. I went through these instructions in a Leopard machine. To compile in Snow Leopard it's necessary to consider the following notes copied from the Qt 4.6.0 changelog:
- Gcc 4.2 is used by default. Configure with -platform macx-g++40 to select 4.0.
- Using the 10.4u SDK requires gcc 4.0.
- Configuring for the Cocoa port (-cocoa) produces 64-bit binaries by default. Use the -arch flags to override.
- Building for ppc64 is no longer supported by the gcc tool chain.
- Building for ppc is still supported.
I haven't tried to generate universal binaries on a Snow Leopard machine. We have to validate these steps.
Building stellarium itself
Create a build directory with your favorite shell (the following directory is just an example, you can pick any name and path you want)
$ mkdir ~/Development $ cd ~/Development
And in that directory checkout the sources with the svn command
$ svn co https://stellarium.svn.sourceforge.net/svnroot/stellarium/trunk/stellarium stellarium
Time to compile stellarium
We setup the build directory
$ cd stellarium $ mkdir -p builds/macosx $ cd builds/macosx
We run cmake and compile
$ cmake ../.. $ make
$ make install $ make macosx_bundle
The macosx_bundle target includes a perl script that makes use of otool and install_name_tool to:
- read the link dependencies of Stellarium.app/Contents/MacOS/stellarium
- copy those dependencies into the app (.frameworks and .dylibs)
- recurse on those copied-in dependencies, stopping at a point where system libraries are called for
This seems to work for making a relocatable Stellarium.app. Making a universal build from here is a matter of taking an intel and a ppc and merging them appropriately.
I've found that making a universal app directly via cmake to not work, even the better mac-supporting 2.6. Any insights appreciated!
To get CMake to do all the packaging and linking above (to take better advantage of cmake 2.6), we need to re-arrange the CMAke properties a bit across all the ports, and this is a somewhat larger undertaking.
Updating source code
You can check to see if the source code has been updated on the server at any time by going in a terminal window to
And entering the command
svn -u status
Any file that it mentions is either changed locally, or changed on the server (svn help status for details of the output of this command). Unless you are working on the source code yourself, anything mentioned is an update. You can update from this directory also with
IMPORTANT: you should delete or move aside the old /Users/Shared/stellarium/Stellarium.app before each new build.
Why Not Xcode?
Cmake has an Xcode generator (as opposed to "Unix Makefiles"), now in 2010, this seems to be working better. One wants to choose the macosx_bundle target, and build it. This author prefers the unix makefiles, but now happily it's just a matter of preference.
Getting a universal build out of Xcode depends entirely on having universal libraries for all the dependencies.
Cmake generally has made this whole compilation process on the mac both more repeatable, and more like the other platforms (or, at least, more like the unix and such...). This is a Good Thing.
All kinds of things might go wrong!
- if the cmake or the build complains about a missing library, it might need installation. Start with fink.
- if the compilation breaks on some code, it may be that the developers are in the middle of something, and come back in a svn revision or so.
- anything else I haven't remembered or encountered!
Loadable Module Support
I was able to get loadable module support working, and have submitted patches for the CMakeLists.txt files in StellaGui and HelloStelModule. These build straightforwardly:
- edit the top-level CMakeLists.txt file to point to where your real stellarium source and build directories are.
- make builds/macosx and cd to it
- run cmake and make:
cmake -G "Unix Makefiles" ../.. make make install
and you should have StellaGui or HelloStelModule as a directory in builds/macosx, which you can copy to ~/Library/Preferences/Stellarium/modules/ (you may have to make that directory).