Hello Barney & all, I've been following your messages with some interest, as I too have been trying to build a more-modern ghc on my G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and tried to build 6.8.3; I'm finally at the point where I have something to report, although I'm not sure if it's a success or a failure report... :-/ I applied your patch to package.conf.in (approximately; the relevant section wasn't quite identical), edited rts/Linker.c to add "#define LC_SEGMENT_64 LC_SEGMENT", and hacked up a wrapper script around ar to always ranlib the library being processed; you had mentioned patching cabal, but I decided the wrapper around ar was easier... a hack, but what the hell. After that, "configure && make" ran to completion without errors (although it took a couple of days, since I had all the extralibs). Success! ... or is it? I installed the new compiler into /usr/local, then tested it by trying "ghc -v". Alas, no joy! It died with some dynamic-link error which I've approximately reproduced here: lupus:~/ghc-6.8.3% ghc-6.8.3 -v dyld: relocation error (external relocation for symbol _pthread_mutex_unlock in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap Failure! ... or is it? I thought, how can this be?!? It built itself through stage2, it has to be good! But clearly it isn't... So I tried one last thing: I tried to use the stage1 compiler directly to compile the scheme interpreter I wrote nearly a year ago. That initially failed, too, but for a simple reason, and one I could work around: no readline in ghc 6.8.3. Once I changed the scheme interpreter to not use readline, it compiled, linked, and runs. So... success or failure? I'm really not quite sure... I guess I could try installing the stage1 compiler instead of the stage2 compiler, it seems that it might work. But it would appear that there is still something not entirely right in there. regards, Uwe