RE: GHC-6.4.1 on FreeBSD-amd64 still not ported

2005-10-17 Thread Simon Marlow 
On 15 October 2005 23:10, Wilhelm B. Kloke wrote:

 ghc/includes  
 touch

ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h,mkDerivedC
onstants.c}
 touch

ghc/includes/{mkDerivedConstantsHdr,mkDerivedConstants.o,mkGHCConstants,
mkGHCConstants.o}
 touch ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
 chflags uchg 
 ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h} (cd
 glafp-utils  gmake boot  gmake) (cd ghc  gmake boot  gmake)
 (cd libraries  gmake boot  gmake)
 (cd ghc/compiler  gmake boot stage=2  gmake stage=2)
 (cd ghc/lib/compat  gmake clean; rm .depend; gmake boot
 UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'; gmake -k
 UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files') (cd ghc/rts
  gmake -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files')
 (cd ghc/utils  gmake clean; gmake -k UseStage1=YES
 EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files')   
 gmake hc-file-bundle Project=Ghc

Thanks very much for this, I'll update the docs.

 Don't forget to delete Linker.c (for ghci). The stage on teh host
 system 
 where the process fails jsut now is
 $MAKE -C libraries boot all
 because
 Fake happy is not happy!

You mean on the target system?  Can you give more details?
 
 But ghc-inplace seems to work pretty good now on amd64.

Great!

Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC-6.4.1 on FreeBSD-amd64 still not ported

2005-10-15 Thread John Hornkvist 
Simon Marlow simonmar at microsoft.com writes:


 
 SIZEOF_mp_limb_t comes from DerivedConstants.h, and SIZEOF_VOID_P comes
 from ghcautoconf.h (both in ghc/includes).  Both of these files should
 be from the target system for a cross-compile; I strongly suspect that
 one of them has been overwritten by the host version in your tree.

Those files got overwritten several times for me, too, despite following the
instructions... I ended up watching for them to get overwritten and copying 
them back whenever that happened.

I've been trying to crosscompile for amd64-freebsd from Mac OS X, but 
although I seem to get all the hc files, the ghc-pkg-inplace crashes, and 
so does ghc-inplace, with the following backtrace:

#0  0x014f3ed0 in StgRun ()
#1  0x014f09b5 in schedule ()
#2  0x014f1386 in waitThread_ ()
#3  0x014f12aa in scheduleWaitThread ()
#4  0x014ee421 in rts_evalLazyIO ()
#5  0x014edccf in main ()

Should I try to build again with debug symbols, or is that pointless for ghc 
output?

Thanks,
John


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC-6.4.1 on FreeBSD-amd64 still not ported

2005-10-15 Thread Wilhelm B. Kloke 
John Hornkvist [EMAIL PROTECTED] schrieb:
 Simon Marlow simonmar at microsoft.com writes:

 SIZEOF_mp_limb_t comes from DerivedConstants.h, and SIZEOF_VOID_P comes
 from ghcautoconf.h (both in ghc/includes).  Both of these files should
 be from the target system for a cross-compile; I strongly suspect that
 one of them has been overwritten by the host version in your tree.

 Those files got overwritten several times for me, too, despite following the
 instructions... I ended up watching for them to get overwritten and copying 
 them back whenever that happened.

This is not really sufficient. I use chflags uchg to protect these
files. At least you you will be noticed, when the overwrite tries to happen.

 I've been trying to crosscompile for amd64-freebsd from Mac OS X, but 
 although I seem to get all the hc files, the ghc-pkg-inplace crashes, and 

Are you sure? The recommended procedure has a serious bug, which I
discovered about 30 minutes ago. You need to do make boot in the rebuilding
of ghc/lib/compat with the same flags as make all, because libghccompat.a
is built in make boot and you won't get the .hc files otherwise.
Just look into ghc/lib/Compat subdirectories for .hc files.

 so does ghc-inplace, with the following backtrace:

 #0  0x014f3ed0 in StgRun ()
 #1  0x014f09b5 in schedule ()
 #2  0x014f1386 in waitThread_ ()
 #3  0x014f12aa in scheduleWaitThread ()
 #4  0x014ee421 in rts_evalLazyIO ()
 #5  0x014edccf in main ()

 Should I try to build again with debug symbols, or is that pointless for ghc 
 output?

This is  pointless, and typical for the sort of errors SM mentioned.
I have got dozens of these in the process.

Now let me report real progress. I have got it on FreeBSD-6.0-amd64 at last.

Here are the steps on the host system, which are needed IIRC:

cp 
../../fptools-amd64/ghc-6.4.1/ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
 ghc/includes
touch 
ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h,mkDerivedConstants.c}
touch 
ghc/includes/{mkDerivedConstantsHdr,mkDerivedConstants.o,mkGHCConstants,mkGHCConstants.o}
touch ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
chflags uchg  ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}
(cd glafp-utils  gmake boot  gmake)
(cd ghc  gmake boot  gmake)
(cd libraries  gmake boot  gmake)
(cd ghc/compiler  gmake boot stage=2  gmake stage=2)
(cd ghc/lib/compat  gmake clean; rm .depend; gmake boot UseStage1=YES 
EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'; gmake -k UseStage1=YES 
EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files')
(cd ghc/rts  gmake -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files')
(cd ghc/utils  gmake clean; gmake -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C 
-keep-hc-files')
gmake hc-file-bundle Project=Ghc

Don't forget to delete Linker.c (for ghci). The stage on teh host system
where the process fails jsut now is
 $MAKE -C libraries boot all
because 
 Fake happy is not happy!

But ghc-inplace seems to work pretty good now on amd64.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: GHC-6.4.1 on FreeBSD-amd64 still not ported

2005-10-13 Thread Simon Marlow 
On 12 October 2005 17:34, Wilhelm B. Kloke wrote:

 Simon Marlow [EMAIL PROTECTED] schrieb:

 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.
 
 This doesn't work. The commands don't leve a .hc file behind, even
 with make -k. 

My apologies: the failure was happening before generation of the .hc
file.  The error is generated by this in Cmm.h:

#if SIZEOF_mp_limb_t != SIZEOF_VOID_P
#error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false
#endif

SIZEOF_mp_limb_t comes from DerivedConstants.h, and SIZEOF_VOID_P comes
from ghcautoconf.h (both in ghc/includes).  Both of these files should
be from the target system for a cross-compile; I strongly suspect that
one of them has been overwritten by the host version in your tree.

Sorry that this process is somewhat flaky; we've never got around to
making the build system really do cross-compilation properly, and the
fact that it usually only needs to be done once for any given platform
means there isn't a lot of motivation to do the work.

Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC-6.4.1 on FreeBSD-amd64 still not ported

2005-10-12 Thread Wilhelm B. Kloke 
Simon Marlow [EMAIL PROTECTED] schrieb:
 On 25 September 2005 18:54, Wilhelm B. Kloke wrote:

 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.

This doesn't work. The commands don't leve a .hc file behind, even with
make -k. I ieven tried using the command line alonei for Appy.hc. This did
not work either. The I commented out the #error in line 288 of Cmm.h.
After this I got the following error:

~/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/rts 0$ ../../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-O -fvia-C -keep-hc-files -c Apply.cmm -o Apply.o
Cmm lint error:
  in proc stg_ap_0_ret
in basic block c2
  in assignment: 
R1 = I32[R1 + 8 + 0];


Compilation had errors

so it looks as if there is a more severe problem remaining.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: GHC-6.4.1 on FreeBSD-amd64 still not ported

2005-10-05 Thread Simon Marlow 
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users