OSXHorrors » History » Version 19

Chris Cannam, 2011-03-24 10:04 AM

1 1 Chris Cannam
2 1 Chris Cannam
{{>toc}}
3 19 Chris Cannam
4 19 Chris Cannam
h1. OS/X version, hardware platform, and Qt version compatibility
5 18 Chris Cannam
6 6 Chris Cannam
*Executive summary:* For a program like EasyHg that demands the widest possible compatibility, we currently want to hit the following targets:
7 6 Chris Cannam
8 6 Chris Cannam
* 10.4 PPC 32-bit Carbon
9 6 Chris Cannam
* 10.4 Intel 32-bit Carbon
10 6 Chris Cannam
* 10.6 Intel 64-bit Cocoa
11 1 Chris Cannam
12 8 Chris Cannam
To do this, we currently need at least two builds of Qt:
13 8 Chris Cannam
14 12 Chris Cannam
* 10.6 gcc-4.2 Cocoa x86_64
15 8 Chris Cannam
* 10.4 gcc-4.0 Carbon PPC and i386
16 1 Chris Cannam
17 15 Chris Cannam
This should mean the Qt 4.7.1 default distribution plus a separate Carbon build will do.  BUT see Qt Plugins and Python sections below.
18 9 Chris Cannam
19 1 Chris Cannam
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.
20 12 Chris Cannam
21 12 Chris Cannam
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.
22 1 Chris Cannam
23 5 Chris Cannam
h2. OS/X 10.6
24 5 Chris Cannam
25 1 Chris Cannam
h3. As target
26 1 Chris Cannam
27 11 Chris Cannam
* By far the most common version as of Feb 2011 (apparently >80%)
28 5 Chris Cannam
* Not supported on PPC
29 5 Chris Cannam
* Runs in 64-bit mode by default where possible
30 10 Chris Cannam
* Note Python is also 64-bit by default, so PyQt needs to be as well
31 5 Chris Cannam
* Is _not_ always 64-bit -- it is supported on 32-bit-only hardware such as Core Duo (first Intel Macs)
32 1 Chris Cannam
33 1 Chris Cannam
h3. As build host
34 1 Chris Cannam
35 5 Chris Cannam
* Builds 64-bit by default
36 5 Chris Cannam
* Can be used to do 32-bit Intel and PPC builds
37 1 Chris Cannam
38 1 Chris Cannam
h2. OS/X 10.5
39 1 Chris Cannam
40 1 Chris Cannam
h3. As target
41 1 Chris Cannam
42 2 Chris Cannam
* 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
43 1 Chris Cannam
* Last version supported for PPC platforms
44 1 Chris Cannam
* Runs in 32-bit mode by default
45 1 Chris Cannam
* Can build for it from 10.5, 10.6
46 1 Chris Cannam
* Requires SDK @/Developer/SDKs/MacOSX10.5.SDK@
47 1 Chris Cannam
* First version to support Objective-C 2.0
48 1 Chris Cannam
* Qt Cocoa supported
49 1 Chris Cannam
50 1 Chris Cannam
h3. As build host
51 1 Chris Cannam
52 1 Chris Cannam
* Builds 32-bit by default
53 1 Chris Cannam
* Can be used to do 64-bit builds
54 1 Chris Cannam
55 5 Chris Cannam
h2. OS/X 10.4
56 1 Chris Cannam
57 1 Chris Cannam
h3. As target
58 1 Chris Cannam
59 5 Chris Cannam
* 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
60 5 Chris Cannam
* Appears in PPC and i386 systems
61 5 Chris Cannam
* Runs in 32-bit mode only
62 5 Chris Cannam
* Can build for it from 10.4, 10.5, 10.6
63 5 Chris Cannam
* Requires SDK @/Developer/SDKs/MacOSX10.4u.SDK@
64 5 Chris Cannam
* Requires @-mmacosx-version-min=10.4@ on 10.5+
65 5 Chris Cannam
* Requires gcc-4.0 to be requested explicitly on 10.6
66 5 Chris Cannam
* Does not support Objective-C 2.0
67 5 Chris Cannam
* Not a supported target for Qt's Cocoa builds, Qt Carbon needed
68 2 Chris Cannam
69 2 Chris Cannam
h3. As build host
70 2 Chris Cannam
71 5 Chris Cannam
* Does not support Objective-C 2.0
72 5 Chris Cannam
* 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
73 13 Chris Cannam
74 15 Chris Cannam
h2. Qt Plugins
75 1 Chris Cannam
76 15 Chris Cannam
Qt will by default load any plugins for e.g. image format support that it finds in the system.  There are various ways to block plugin loading (e.g. through build key) but I can't see any way that will prevent Qt from at least dlopen()ing the shared object and rifling through its drawers.
77 15 Chris Cannam
78 15 Chris Cannam
This is a problem, because the plugins have dependencies on the Qt framework components, so we may end up with two different versions of Qt (the one in our bundle and the system one) being loaded at once.  Result: mysterious crashes.
79 15 Chris Cannam
80 17 Chris Cannam
For the moment we "fix" this by applying the following elegant patch to our Qt build:
81 15 Chris Cannam
82 16 Chris Cannam
<pre>
83 16 Chris Cannam
--- src/corelib/plugin/qfactoryloader.cpp_	2011-03-14 12:21:11.000000000 +0000
84 16 Chris Cannam
+++ src/corelib/plugin/qfactoryloader.cpp	2011-03-14 12:22:04.000000000 +0000
85 16 Chris Cannam
@@ -104,7 +104,7 @@
86 16 Chris Cannam
 
87 16 Chris Cannam
 void QFactoryLoader::update()
88 16 Chris Cannam
 {
89 16 Chris Cannam
-#ifdef QT_SHARED
90 16 Chris Cannam
+#ifdef NO_WE_DONT_WANT_PLUGINS_THANKS
91 16 Chris Cannam
     Q_D(QFactoryLoader);
92 16 Chris Cannam
     QStringList paths = QCoreApplication::libraryPaths();
93 16 Chris Cannam
     QSettings settings(QSettings::UserScope, QLatin1String("Trolltech"));
94 16 Chris Cannam
--- src/corelib/plugin/qpluginloader.cpp_	2011-03-14 12:23:31.000000000 +0000
95 16 Chris Cannam
+++ src/corelib/plugin/qpluginloader.cpp	2011-03-14 12:23:53.000000000 +0000
96 16 Chris Cannam
@@ -285,7 +285,7 @@
97 16 Chris Cannam
 */
98 16 Chris Cannam
 void QPluginLoader::setFileName(const QString &fileName)
99 16 Chris Cannam
 {
100 16 Chris Cannam
-#if defined(QT_SHARED)
101 16 Chris Cannam
+#if defined(NO_WE_DONT_WANT_PLUGINS_THANKS)
102 16 Chris Cannam
     QLibrary::LoadHints lh;
103 16 Chris Cannam
     if (d) {
104 16 Chris Cannam
         lh = d->loadHints;
105 16 Chris Cannam
</pre>
106 15 Chris Cannam
107 15 Chris Cannam
h2. Python versions
108 15 Chris Cannam
109 15 Chris Cannam
Python versioning and compatibility is a bit of a nightmare.  We need to load a Python module with C components (using PyQt) in Mercurial, so we need to take into account both the Python version and the architecture.
110 15 Chris Cannam
111 15 Chris Cannam
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.
112 14 Chris Cannam
113 14 Chris Cannam
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.
114 13 Chris Cannam
115 13 Chris Cannam
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.
116 13 Chris Cannam
117 13 Chris Cannam
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.