On 25 September 2005 18:54, Wilhelm B. Kloke wrote:
Though I have reported some sort of success on this in the last days, I was too early. The ghc-inplace does not work on the target system. It compiled because I have been too lax in following the instructions. Here is the report, where the crossport fails on the i386host system:
tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat hc-files-to-go` tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/StgStartup.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/StgStdThunks.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/Updates.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/Apply.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/Exception.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/HeapStackCheck.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/StgMiscClosures.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/libraries/haskell-src/Language/Haskell/Parser.hs: Cannot stat: No such file or directory gmake: *** [hc-file-bundle] Fehler 1
bash-2.05b$ (cd ghc/rts; gmake PrimOps.o ) ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c PrimOps.cmm -o PrimOps.o In file included from PrimOps.cmm:28: /home/wb/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/includes/Cmm.h:288:2: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake: *** [PrimOps.o] Fehler 1
Similar messages for attemps to make other of the failing .hc files. Perhaps crossporting from a 64bit system is easier. I presume that once a working ghc is available, life is much easier, as Fedora Linux-64 does not report problems.
GHC is correctly generating the .hc file from the .cmm file, and then attempting to compile the .hc file using gcc. This latter step fails, as expected, because the .hc code is intended to be compiled on the target system. We just need to get those .hc files and take them to the target. Just doing 'make -k' in ghc/rts should leave all the .hc files behind, because you already have the -keep-hc-files flag in your command line, so GHC won't delete the intermediate .hc files even when the subsequent compilation stage fails. Cheers, Simon