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