Choosing the SDK version

10.4 Tiger is the oldest version of OSX currently supported by Gtk+. To ensure that your programs will run on Tiger, it works best to build with the Tiger sdk (MacOSX10.4u.sdk, specify sdk_version="10.4u" to setup_sdk in your .jhbuildrc-custom). It's been reported that building with the libraries installed in /usr fails on Tiger, but building with the SDK succeeds. Go figure. That means that you must pass sdk_version="10.4u" to setup_sdk.

10.4u is the last SDK version that supports both PowerPC and Intel, so if you want to target PowerPC machines, use 10.4u even if you don't care about Tiger support.

On Lion-compatible versions of XCode, 10.4u and 10.5 SDKs are no longer available. The 10.7 SDK causes problems, so use the 10.6 SDK. See below for more details.

Building GTK for PowerPC on an Intel host

You may need to use a few workarounds to build for a PowerPC target on an Intel host:

If there is an error while compiling gatomic.c, add a new line

#include "gthread.h"

just before line 885.

If there is an error while compiling cairo-mutex-impl-private.h, add a new line

#define CAIRO_NO_MUTEX 1

at the top of the file. The resulting GTK will probably only be reliable for single-threaded applications.

Building GTK under Tiger

The zlib bundled with Tiger doesn't export deflateSetHeader and inflateGetHeader (bug #662826), so you will need to change the line

#if !defined (G_OS_WIN32) || ZLIB_VERNUM >= 0x1240

in gzlibcompressor.c and gzlibdecompressor.c to

#if 0

The resulting glib will still be able to compress and decompress .gz files, but it won't have access to the filename and timestamp in the GZIP header.

The zlib bundled with Tiger also doesn't export gzdirect, which is used in xmlIO.c (bug #662827). One way to work around this is by changing

#if defined(ZLIB_VERNUM) && ZLIB_VERNUM >= 0x1230

to

#if 0

Unlike the gzlibcompressor.c/gzlibdecompressor.c change, the xmlIO.c change is somewhat problematic because this change will break zlib versions newer than 1.2.3; Lion comes with version 1.2.5. If the application(s) you're building don't use libxml2, don't process gzipped XML files, or if you will only be running them on Tiger/Leopard/Snow Leopard, this is not a concern.

Snow Leopard and Later OSX Versions

Snow Leopard and later default to building 64-bit binaries (for Snow Leopard that's true only on a 64-bit machine; later versions run only on 64-bit hardware). Resulting binaries will, of course, work only on 64-bit machines. For maximum portability of your binaries, include

moduleset = "http://git.gnome.org/browse/gtk-osx/plain/modulesets-stable/gtk-osx.modules"
setup_sdk(target="10.4", sdk_version="10.4u", architectures=["i386"])

in your .jhbuildrc-custom. Note that the revisions of pango, cairo, and gtk+ are held back for Tiger compatibility -- but won't run successfully if built for 64-bit. More details on 64-bit building is available at the Snow Leopard page.

For GTK to work under Lion, you will also have to link against Apple's version of libiconv rather than the one in the moduleset. To do this, specify the option --skip=libiconv on the jhbuild bootstrap commandline.

Lion adds another wrinkle: XCode 4.1, the minimum version which works on it, doesn't include the 10.4 and 10.5 SDKs. Worse, unlike with XCode 4.0 on Snow Leopard, it doesn't link properly if you try to copy over the SDKs from a Snow Leopard installation of XCode 3.x. Because most Gtk applications will be pulling in some libraries from SDK.../usr/lib, if the older version of OSX has an older version of some library than supplied in the SDK you used, the program will fail to launch on the older system.

There's another issue with building on Lion or Mountain Lion using either "native" or the 10.7 SDK: Apple has updated the pthreads implementation to provide recursive locking. This would be good except that Gettext's libintl uses this and if the pthreads implementation doesn't provide it it fabricates its own. Since the Lion pthreads does provide it, libintl links the provided function and then crashes when you try to run it against an older version of the library. The simplest solution is to specify the 10.6 SDK when building on Lion, but that won't work on Mountain Lion, which doesn't include it. See below for how to install and use XCode 3 on Lion and later for building applications compatible with earlier versions of OSX.

On Lion, it's not possible to build for a PowerPC target for several reasons: First, there is no way to use the 10.4u SDK, and gcc can't produce PowerPC object code. It might be possible to work around this by building a cross-compiler or by shoehorning in pieces of old XCode. Second, there is no longer an emulation mode to run PowerPC binaries on an Intel host, so configure's test programs won't run. (For a similar reason, it's not possible, under any OS version, to build Intel binaries of GTK on a PowerPC host.) This, too, could possibly be resolved, by making jhbuild use configure's --host and --build options.

XCode4

Apple released XCode version 4 in February, 2011. They made a lot of changes to the GUI, but almost none to the parts we care about (gcc is still v4.2.1, for example). One change they make was to remove PPC images from several libraries, including Expat. They didn't change the default architectures in Perl's ExtUtils::MakeMaker, though, so it continues to try to build PPC binaries. This causes trouble during bootstrap when we're trying to install XML::Parser. The fix is to add this to your environment:

export ARCHFLAGS="-arch x86_64 -arch i386"

or add to your jhbuildrc-custom

os.environ["ARCHFLAGS"] = "-arch x86_64 -arch i386"

This is already handled for you with recent versions of .jhbuildrc

If you use CPAN, you may want to add the equivalent (`%ENV{ARCHFLAGS}=...`) to MyConfig.pm, since quite a few useful CPAN modules fail to build otherwise.

XCode 4.2, which shipped with Lion, and XCode 4.4, which shipped with Mountain Lion, corrected the Perl problem from XCode 4.0. However, backward compatibility is not well supported. For one thing, Apple has discontinued using gcc and replaced it with llvm. This compiler supports multiple front ends, and Apple provides two: Clang, which is the default when building with XCode, and llvm-gcc, provided for compatibility. llvm-gcc works well enough for building GTK applications, but requires new SDKs. XCode3 SDKs won't work. XCode 4 ships with SDKs for the target and preceding OSX versions only: 10.6 and 10.7 in XCode 4.0 and 4.2 for Lion, and 10.7 and 10.8 in XCode 4.4 for Mountain Lion.

Unfortunately Apple's deployment target magic only works on Apple's frameworks, not on the Unix libraries we depend upon, so the oldest version SDK you build with is the oldest OS version you can run on. In other words, you can specify setup_sdk("10.4", "10.6", ["i386"]) in your .jhbuildrc-custom, and it will build, but it won't actually run on a Tiger or Leopard system because the linked-in versions of some of the libraries in /usr/lib are too new. It's best to use XCode 3 for backwards compatibility.

Installing XCode 3 on XCode 4 systems

Download xcode_3.2.5_and_ios_sdk_4.2_final.dmg, open the dmg and start the installer. Note: The link doesn't always work directly: After logging in, it may take you to the generic developer downloads page. If the category isn't "Developer Tools", select that from the list on the right, then search that page for 'xcode 3' and you should find the correct link.

On the fourth screen (Installation Type), unselect everything except Essentials and pick a new install location using the combo box on the Essentials line. If you want to build for Tiger, you'll need to select the 10.4 SDK as well.

Continue the installation.

You can now set (via your .jhbuildrc-custom) the 10.5 or 10.4u SDK and build. Note that the 10.4 SDK requires gcc-4.0, which is provided by XCode 3 and not XCode 4 (which doesn't actually have gcc at all, as noted above). If you set $DEVELOPER_DIR to point to your XCode 3 installation (export DEVELOPER_DIR=/Developer if you took the default installation location) and add $DEVELOPER_DIR/usr/bin to the front of $PATH then .jhbuildrc will use the XCode 3 tools without further intervention. Note that XCode 3's xcodebuild (used by .jhbuildrc to detect the XCode version) needs java, so you'll be prompted to install it on Lion or Mountain Lion.

One more small issue: perl-xml-parser won't build with this lash-up, so add skip.append("perl-xml-parser") to your .jhbuildrc-custom. It's already installed and it's used by jhbuild itself, so it's not really necessary to build our own.

Projects/GTK/OSX/OSX Version Notes (last edited 2018-12-05 15:46:39 by EmmanueleBassi)