Op maandag 15-06-2009 om 15:30 uur [tijdzone +0200], schreef Erik van Pienbroek:
Now about the results: With this toolchain I managed to get one of my personal open source projects, NNTPGrab [9], operational, but there are still some strange bugs involved. This project is a GTK based application which makes use of GObject signals. In my first try on the Mac OS X toolchain, the signals were emit, but the parameters in the callback functions were always NULL. After that I dropped some potentially conflicting files from the SDK (headers installed by GCC) and rebuild everything. Now the GObject signals work fine, but the fonts are really messed up. It's basically the same as described in a WebKit bug report [10] as I've also seen the same error message while running my application. Unfortunately I don't have a solution to that yet, but I suspect it's caused by a compiler mismatch (Mac OS X 10.4 is based on GCC 4.0 while Mac OS X 10.5 is based on GCC 4.2).
Hi all,
In the last few days I continued with the toolchain. I discovered that the Apple upstream of odcctools has been revived for Mac OS X 10.6 (Snow Leopard) support: http://svn.macosforge.org/repository/odcctools/trunk/ChangeLog.odcctools Because of this I replaced the odcctools from the iphone-dev project (based on cctools-622.3) with the odcctools tools from Apple (based on cctools-698.1).
This update was also necessary to generate a compiler based on the Mac OS X 10.5 SDK. Next to this, I also discovered some hidden environment variables which are needed to indicate which version of Mac OS X is required to run the application. The entire SDK has also been moved to a separate directory (%{_darwinx_sysroot}/SDKs) just like regular Mac OS X environments and this location has been added to the CFLAGS in the %{_darwinx_configure} script.
I'm still rebuilding all the packages, but I hope to get more satisfying results than before.
So what's next to happen? Here's a small list of tasks which need to be done before everything can be imported in Fedora or RPMFusion: - Support for fat/universal binaries This requires multiple GCC compilers which are tied together by a small wrapper. This wrapper (which is called /usr/bin/gcc on regular Mac OS X environments) accepts arguments like '-arch i386 -arch ppc' and calls the corresponding compilers and uses lipo to merge the results together - License research This consists of three major questions: - Are we allowed to redistribute XCode/the SDK or could we get an exception from Apple for this? - Are the APSL 2.0 + GPL bits enough to get applications working? - Can we regenerate the .dylib files which are bundled with the SDK from source code (which is a requirement for Fedora) so that we get something like w32api? - Debug symbols On regular Mac OS X environments GCC executes a tool called 'dsymutil' during the compilation. This tool is required to add debug information to libraries/executables. Without this information only function names will be shown in gdb (no line numbers etc). AFAIK the source code of this tool isn't available. For now I've patched the calls to 'dsymutil' out of gcc so that the compilation of libraries/executables shouldn't fail - Merge the .spec files for the normal libraries (pixman, cairo, gtk2, etc) with their mingw32 counterparts The discussion about this was already started in this thread, but it's kinda dependent on the results of the license research. For fat/universal binaries one doesn't need to perform separate compile passes for each platform (ppc/i386/x86_64) as that all happens in one go (when the gcc wrapper I spoke of earlier is in place) - End user installers We need something like nsiswrapper for Mac OS X environments. On Mac OS X environments, all applications are bundled in one directory, a so called '.app'. This directory contains some standard files (containing application information, an icon, etc) and of course the application itself along with it's dependencies and data files. These .app folders can be packed in a .zip file or a .dmg file which end-users can open directly to run/install the application
There probably are more tasks remaining to be done, but these are the things that came to my mind while writing this status update.
Regards,
Erik van Pienbroek