Donald Bruce Stewart
dons at cse.unsw.edu.au
Fri Oct 17 12:10:11 EDT 2003
I will describe what I have done to reach the point I am at on
The machine I am using reports as an "IRIX64 6.5 IP30 mips" machine.
The host machine for all these builds was a i386-*-openbsd machine.
Before you can start you need to install GNU tools. I used
also, as a precaution, I installed the latest libgmp: gmp-4.1.2.
On this machine at least I can set a compiler flag and get either 64
or 32 bit longs, corresponding to a 64 or 32 bit compiler.
I tried 32 bits first. This is the default mode on the machine, and
requires no special flags.
On the .hc host
* be careful on the host machine to write the TARGET_ARCH variable when
generating hc files, as mipseb_TARGET_ARCH or you will get strange errors
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
* 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.
Using an extenal gmp, and reconfiguring it for a variety of mips
machines didn't solve this.
So at this point I decided to try to build a 64 bit ghc.
* you have to add the same 64 bit fixes in cvs that were needed for
alpha, and that were discussed a few weeks ago. The patches are
attached, for MBlock.h, MBlock.c, PrimOps.h and RtsUtils.h
* before you build, you have to tell ./configure's gcc that you want to
use the 64 bit abi:
note that I still let the machine be detected as mips-sgi-irix. I
haven't seen a problem with this yet, as there is so little mips code in
ghc in the first place.
* but we also have to tell the gcc that compiles ghc how to get 64 bit
longs. So in mk/build.mk add:
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
I am not sure if these are significant.
Also, the bugs in the 32 bit build, with pkg-conf, gmp and decodeDouble
do not occur.
* 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:
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.
This file is generated by utils/genapply. If you run it after it is
built for .hc files, it generates these faulty chars.
So, somehow the .hc files generated on the host machine are being
miscompiled on the mips machine. The rest of AutoApply.hc is fine. Only
the ARG_xxx symbols are wrong. If you copy in a working AutoApply.hc
(e.g. the one on the host machine) then the file compiles, and the rts
compiles. Then we try to compile the libraries with ghc. But ghc
generated .hc files -fvia-C, and these files have this bug too!
A faulty ghc has been built that inserts the wrong characters in some
places in .hc files, but not all or even most.
I haven't solved this, but am attempting to generated host .hc files on
an 64 bit machine (ia64) to see if this is a 32/64 bit bug. Otherwise
we may need SimonM.
More information about the Glasgow-haskell-users