When last we spoke I left on a rather uncertain note. But will it work... I asked. The immediate answer to that query was No. It will not. Being far too persistent with these things I kept on working until the answer was Yes. I have defeated you, vile beast. Yes, dramatic. I know. The thing is, after getting apple-gcc42 to compile and install it was able to build programs just fine; unless I wanted to use the MacOSX10.4u.sdk to compile universal binaries (hereafter referred to as fat files).

The solution was to ditto the fake gcc install directory (destroot?) into /Developer/SDKs/MacOSX10.4u.sdk/. Things were mostly all good (ran into some issues but all were fixable) until I started compiling stuff which used cmake. Strigi, my cmake de-virginizer, kept on failing with the error:

Insert error here

It wouldn't work until I made a symbolic link from /opt to /Developer/SDKs/MacOSX10.4u.sdk/opt. After that macports happily complied with my requests to compile universal binaries so long as I added the necessary flags to the Portfile. I also needed to remove an automatic addition macports made to all ports under the assumption that they were using the autoconf-based configure script to be configured. The magic is shown below:

variant universal description "Compile for ppc and intel architectures" {
    configure.universal_args-delete  --disable-dependency-tracking
    configure.args-append       -DCMAKE_OSX_ARCHITECTURES=\"ppc\;i386\"
}

You'll notice a lot of talk about gcc 4.2 here and you may be wondering how I got macports to do that. I edited the opt/local/share/macports/Tcl/port1.0/portconfigure.tcl. A diff showing the changes is below. As you'll see I just manually pointed macports to the location of my gcc compilers.

--- portconfigure.tcl2  2008-09-20 23:49:12.000000000 -0400
+++ portconfigure.tcl   2008-09-20 23:48:17.000000000 -0400
@@ -96,10 +96,10 @@
 options configure.ccache configure.distcc configure.cc configure.cxx configure.cpp configure.objc configure.f77 configure.f90 configure.fc configure.javac configure.compiler
 default configure.ccache        {${configureccache}}
 default configure.distcc        {${configuredistcc}}
-default configure.cc            {}
-default configure.cxx           {}
-default configure.cpp           {}
-default configure.objc          {}
+default configure.cc            {"/usr/bin/gcc-4.2"}
+default configure.cxx           {"/usr/bin/g++-4.2"}
+default configure.cpp           {"/usr/bin/cpp-4.2"}
+default configure.objc          {"/usr/bin/gcc-4.2"}
 default configure.f77           {}
 default configure.f90           {}
 default configure.fc            {}

So basically everything will be packaged up using one compiler, gcc 4.2. Well, almost. I had trouble with two packages: subversion and kdepimlibs and ended up having to revert to gcc 4.0 to use them. Subversion just went bats**t crazy when apple-gcc 4.2 was used, which is interesting since none of its dependencies, like apr, did.

Insert madness here

The problems with kdepimlibs wasn't actually the fault of kdepimlibs. I believe it stems from an issue with this version of Apple's gcc 4.2 having a bug when compiling inline asm code (which the boost headers used by kdepimlib use). Game over. Not much I can do about that except update gcc, which of course, I had trouble doing.

Much incentive for moving over to Leopard and just compiling 10.4 universal binaries there though. The problem (isn't there always one of those) is that the 10.4u SDK only compiles w/ gcc 4.0 and not 4.2. Waitminute, isn't that what I just did above ...