> Using ghc 6.0 with this script it felt like I was getting most of the
> way to an Alpha Linux compiler from an x86 Linux one. It fails with
> 
> gcc -x c GHC/Int.hc -o GHC/Int.raw_s -S -O  -mieee  -static 
> -w -D__GLASGOW_HASKELL__=600  -O 
> -I/home/igloo/ghc/ghc-6.0/ghc/includes 
> -I/home/igloo/ghc/ghc-6.0/libraries/base/include 
> -I/home/igloo/ghc/ghc-6.0/hslibs/lang/cbits 
> -I/home/igloo/ghc/ghc-6.0/hslibs/posix/cbits 
> -I/home/igloo/ghc/ghc-6.0/hslibs/util/cbits 
> -I/home/igloo/ghc/ghc-6.0/hslibs/text/cbits 
> -I/home/igloo/ghc/ghc-6.0/hslibs/hssource/cbits    -I.  `echo 
>  | sed 's/^$/-DSTOLEN_X86_REGS=4/'`
> GHC/Int.hc: In function `sbsy_ret':
> GHC/Int.hc:3092: `int64ToIntegerzh_fast' undeclared (first 
> use in this function)
> GHC/Int.hc:3092: (Each undeclared identifier is reported only once
> GHC/Int.hc:3092: for each function it appears in.)
> GHC/Int.hc: In function `sbst_ret':
> GHC/Int.hc:3169: `int64ToIntegerzh_fast' undeclared (first 
> use in this function)
> make[1]: *** [GHC/Int.raw_s] Error 1
> 
> I'm not sure how to fix this - I can give 'config.h's from the target
> system and recompile the library '.hc's, but I think the 
> generated code
> also depends on the compiler which will break if compiled 
> with the wrong sizes. Any suggestions?

This is the right thing to do: you should take config.h from the Alpha
and plug it into your Linux build.  You want the compiler to generate
.hc code for a 64-bit system, and using the Alpha's config.h will cause
it to do this.

However, you might be unable to compile the resulting .hc's down to .o
on the Linux box, which means the build might fail.  This is harmless,
because we don't need the .o's, but you might need to work around it
somehow.

> Here are the things I've had to do to get this far:
> 
> Normal gcc 3.3 fixes:
> ghc/compiler/nativeGen/MachMisc.lhs
> ghc/compiler/nativeGen/RegAllocInfo.lhs
> ghc/driver/mangler/ghc-asm.lprl

Check out the latest code from CVS on the 6.0 branch.  I've just merged
across an important fix for unregisterised code, too.

> Files copied across to the alpha:
> b1: "*.hc", "*_hsc.c" package.conf
> b2: "*.hc", ".depend*"

package.conf and .depend* shouldn't be necessary, but I haven't got as
far as checking the HC bootstrapping phase here yet.

> Comment out the $(AUTO_APPLY) rule in ghc/rts/Makefile

I'll take a look at this.

> Make ghc/utils/ghc-pkg/ghc-pkg-inplace a script that just returns true

and this.

> Changed "alpha*-unknown-linux" to "alpha*-unknown-linux*" in configure
> (it's detected as alphaev67-unknown-linux-gnu)

Committed, thanks.

> Change
>     $T_HDR_literal  = "\.rdata\n\t\.align 3\n";
> to
>     $T_HDR_literal  = "\.text\n\t\.align 3\n";
> to fix
>     as    -o Control/Concurrent.o Control/Concurrent.s
>     Control/Concurrent.s: Assembler messages:
>     Control/Concurrent.s:8: Error: unknown pseudo-op: `.rdata'
> A quick google suggests this might be an alpha-linuxecoff vs 
> elf issue, but I don't know anything about this.

I don't know anything about this either.

> The dependency files still try to get built, but $(MKDEPEND_HS) is
> empty. As it happens this means the line ends up starting -M so make
> tried to run M, fails because it doesn't exist but continues thanks to
> the -.

This shouldn't happen; I'll look into it.

Cheers,
        Simon
_______________________________________________
Cvs-fptools mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-fptools

Reply via email to