simonmar:
There's a small possibility that I've missed something out from the instructions, I suppose :)
No. They are perfect. I've stress tested them today :p
+-----------------+--------------------+----------------------------+ | HOST | TARGET | Unregisterised bootstrap | +-----------------+--------------------+----------------------------+ | i386-*-openbsd | i386-*-openbsd | YES | | | i386-*-freebsd | YES | | | i386-*-linux | YES | | | i386-*-solaris2 | YES | | | sparc-sun-solaris2 | YES | | | sparc-sun-openbsd | in-progress | | | m68k-apple-netbsd | in-progress | | | | | | | alpha-dec-osf3 | dies on host with: | | | | cc1: Invalid option `ieee' | +-----------------+--------------------+----------------------------+
So all 32-bit platforms have worked or are looking good, but the 64 bit couldn't get of the host machine.
The problem you experienced on the Alpha has a perfectly rational explanation. The .hc files we generate on the host machine are designed to be compiled on the target machine only; it's entirely possible that the configuration of the compiler on the host machine may not be able to compile these .hc files to .o. Ideally, the build system should know when it is cross-compiling .hc files and just generate .hc files (passing -C to GHC instead of -c -keep-hc-files). I thought about doing this, but quickly realised it would be a lot of work to get right. You might be able to hack around it with lots of 'make -k' on the host machine.
But I think we can see that GHC is portable now :)
That's what I like to hear :-) Cheers, Simon