OSXHorrors » History » Version 14

« Previous - Version 14/29 (diff) - Next » - Current version
Chris Cannam, 2011-03-21 06:02 PM


OS/X version, hardware platform, and Qt version compatibility

Executive summary: For a program like EasyHg that demands the widest possible compatibility, we currently want to hit the following targets:

  • 10.4 PPC 32-bit Carbon
  • 10.4 Intel 32-bit Carbon
  • 10.6 Intel 64-bit Cocoa

To do this, we currently need at least two builds of Qt:

  • 10.6 gcc-4.2 Cocoa x86_64
  • 10.4 gcc-4.0 Carbon PPC and i386

This currently means the Qt 4.7.1 default distribution plus a separate Carbon build will do.

Note it is not possible to cover all platforms in a single build step, we always need to do at least two separate builds plus lipo.

If we are going to make a 3-way universal binary, we need to ensure the 10.4 build gets selected for i386 -- i.e. to pull only the x86_64 architecture from any 10.5 or 10.6 SDK build we do. The inability to select between different i386 versions from a single universal binary is a strong incentive to stick to a single 10.4+ Carbon build for all 32-bit platforms.

OS/X 10.6

As target

  • By far the most common version as of Feb 2011 (apparently >80%)
  • Not supported on PPC
  • Runs in 64-bit mode by default where possible
  • Note Python is also 64-bit by default, so PyQt needs to be as well
  • Is not always 64-bit -- it is supported on 32-bit-only hardware such as Core Duo (first Intel Macs)

As build host

  • Builds 64-bit by default
  • Can be used to do 32-bit Intel and PPC builds

OS/X 10.5

As target

  • Not all that much more widely used than 10.4 -- if we were dropping 10.4, we probably might as well drop 10.5 as well
  • Last version supported for PPC platforms
  • Runs in 32-bit mode by default
  • Can build for it from 10.5, 10.6
  • Requires SDK /Developer/SDKs/MacOSX10.5.SDK
  • First version to support Objective-C 2.0
  • Qt Cocoa supported

As build host

  • Builds 32-bit by default
  • Can be used to do 64-bit builds

OS/X 10.4

As target

  • Oldest version still apparently in use as of Feb 2011: not very widespread (low single digit %age of Mac users), but at least two researchers here use it
  • Appears in PPC and i386 systems
  • Runs in 32-bit mode only
  • Can build for it from 10.4, 10.5, 10.6
  • Requires SDK /Developer/SDKs/MacOSX10.4u.SDK
  • Requires -mmacosx-version-min=10.4 on 10.5+
  • Requires gcc-4.0 to be requested explicitly on 10.6
  • Does not support Objective-C 2.0
  • Not a supported target for Qt's Cocoa builds, Qt Carbon needed

As build host

  • Does not support Objective-C 2.0
  • 10.4u SDK can be used to build 64-bit executables of simple C/C++ programs such as plugins, but not of GUIs or anything using Core frameworks

Special note about Python

Python versioning and compatibility is a bit of a nightmare. The system Python is 2.5 on 10.4/10.5 and 2.6 on 10.6. If we're using PyQt, we need to build for 2.5 if it's to work across all our targets.

On 10.6, Python is 32-/64-bit universal which runs in 64-bit by default on a 64-bit system, so any modules need to be available both ways as well (troubleshooting this when it goes wrong is quite tricky). There is an environment variable VERSIONER_PYTHON_PREFER_32_BIT which you can set to cause it always to run in 32-bit.

Where things get complicated is when users install additional versions of Python from other ports repositories; this seems to be quite common around these parts. Then your user-installed Python is likely to get picked up before the system one, and you don't know whether it's going to be 32- or 64-bit, and it won't support the versioning environment variable. My impression is that people get custom Python installs dragged in as dependencies of other packages, and that tends to break quite a lot of things.

Some 10.6 system Pythons have a problem loading modules, apparently something getting broken during the upgrade from 10.5 -- this affects my home machine, but I haven't had time to look into it properly yet.