* 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

* 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.

+

* Cocoa version: Exclusively for Intel architecture and MacOSX 10.5 and later. You can use this if you aren't going to create universal binaries.

== Compiling dependencies to build an universal binary ==

== Compiling dependencies to build an universal binary ==

Revision as of 16:23, 18 February 2010

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.

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 Intel architecture and MacOSX 10.5 and later. 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)

Compiling dependencies

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

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)

Time to compile stellarium

Packaging

IMPORTANT: you should delete or move aside the old /Users/Shared/stellarium/Stellarium.app before each new build.

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.

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.

Troubleshooting

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).