----------- 32 bit mips -----------

* apply rmartine's latest CVS patch to MBlock.c

* The build will go through once, but when you then have to rebuild the rts, pkg-conf will crash creating driver/package.conf.inplace. The solution is to manually echo "[]" > driver/package.conf.inplace, and to touch driver/stamp-pkg-conf-rts

* The build will dump core in the rts. Fire up gdb and you'll see that it died in gmp code around "__gmpn_tdiv_qr".

The solution is to build an external libgmp, and override the target architecture in the gmp build with ./configure --build=mips-sgi-irix. This forces gmp to use 32 bit assembly, rather than going for 64 bit code, which it does by default.

* The build then crashes in __decodeDouble (), in GC.c, I think it was.

There is probably a 32/64 bit mismatch somewhere. You should be able to find out more by compiling up the RTS with debugging options and stepping through decodeDouble (this is ordinary C code).

------ 64 bit ------

The libraries and compiler go though nicely, although you may see warnings of the kind:

ghc/Num.hc:5303: warning: this decimal constant is unsigned only in ISO C90

Might be to do with some 64-bit constants in the generated .hc files, but I'm not sure.

* My current bug: following distrib/hc-build, after bootstrapping ghc/ we rebuild the rts and libraries with the ghc binrary. AutoApply.hc is generated. ghc then can't compile this file. If you look carefully at the bottom of AutoApply.hc you'll see some strange characters:

[ARG_8??] MK_SMALL_BITMAP(3,6), [ARG_8?8] MK_SMALL_BITMAP(3,2), [ARG_88?] MK_SMALL_BITMAP(3,4), [ARG_888] MK_SMALL_BITMAP(3,0), [ARG_8888] MK_SMALL_BITMAP(4,0), [ARG_88888] MK_SMALL_BITMAP(5,0),

This is a problem! The ARG_xxx characters should be either N or P or a some other characters. Not strange ones as we see.

Aha! It looks like toUpper isn't working properly. This is probably because GHC.Unicode has been compiled for a 32-bit machine. This is my fault :-( GHC.Unicode is processed by hsc2hs, which bakes in some platform-specific stuff into the .hs code before compiling it. The trouble is that hsc2hs is currently running on the host machine rather than the target machine, so GHC.Unicode is currently being compiled with 32-bit assumptions. This hasn't been a problem so far because we've eradicated hsc2hs code from the critical path, but I forgot about this when I introduced GHC.Unicode recently. oops! The solution for the time being is to take the C code generated by hsc2hs on the host machine using the --no-compile option, compile & run the program on the target machine using gcc, then take the .hs back to the host machine to generate the .hc file. Or you can wait till I've turned GHC.Unicode back into a plain .hs file. Cheers, Simon