Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)

[Erik van Pienbroek]

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