.hc files for building ghc-6.4.1 on amd64 ?

[Simon Marlow]

On 20 September 2005 12:24, Wilhelm B. Kloke wrote:

> Deletion of Linker.c and manual build of some AutoApply files make
> the crossbuild work on i386 side. I have a copy of the
> resulting hc-bundle ready. If anybody wants them, send me a mail.
> They don't work on the amd64 side, though. Here is the error message:
> 
> gcc -x c GHC/Int.hc -o GHC/Int.o -c -O  -DNO_REGS
> -DUSE_MINIINTERPRETER  -D__GLASGOW_HASKELL__=604  -O
> -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes
> -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include
> -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include
>
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include
>
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/inclu
de
> -I.  `echo  | sed 's/^$/-DSTOLEN_X86_REGS=4/'` GHC/Int.hc: In
> function `s83O_ret':       
> GHC/Int.hc:2522: error: `int64ToIntegerzh_fast' undeclared (first use
> in this function) 
> GHC/Int.hc:2522: error: (Each undeclared identifier is reported only
> once 
> GHC/Int.hc:2522: error: for each function it appears in.)
> GHC/Int.hc: In function `s83J_ret':
> GHC/Int.hc:2583: error: `int64ToIntegerzh_fast' undeclared (first use
> in this function) 
> gmake[1]: *** [GHC/Int.o] Fehler 1
> gmake: *** [all] Fehler 1
> gmake: Leaving directory
> `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries' 

I think this means that something has gone wrong during the generation
of the .hc files on the host machine.  GHC/Int.hc is not supposed to
refer to int64ToIntegerzh_fast, because on a 64-bit machine there is no
Int64# primitive type (it's the same as Int#).  You might want to make
sure that ghc/includes/ghcautoconf.h on the host machine is the right
one - it should have been copied from the target machine.

> I notices that the evil mangler was replaced after my build. I don't
> have 
> an idea whether this would make it work.
> 
> BTW. FreeBSD-amd64 does not seem to support "small memory model". Is
> this essential?

If that's true, it means the port is going to require more work.  But
I'd be surprised, because FreeBSD is using the same compiler toolchain
as everyone else.

Cheers,
	Simon