Re: GHC-6.4.1 on FreeBSD-amd64 port progress
On Wed, Oct 26, 2005 at 06:57:50PM +, Wilhelm B. Kloke wrote: I am able to make the unregisterised .hc-bundle available on the net for other users wanting to install ghc on freebsd-amd64. I would be very grateful if you could make it available. Or is ist better to generate a new registerised .hc-bundle? Right now I simply want to build darcs, so an unregisterised should suffice. Best regards Tomasz ___ 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 port progress
On 26 October 2005 19:58, Wilhelm B. Kloke wrote: Simon Marlow [EMAIL PROTECTED] schrieb: On 25 October 2005 10:01, Wilhelm B. Kloke wrote: Try with splitting off: set SplitObjs=NO in your mk/build.mk. Done with success. I just used the compiler to install darcs. I am able to make the unregisterised .hc-bundle available on the net for other users wanting to install ghc on freebsd-amd64. Or is ist better to generate a new registerised .hc-bundle? A binary distribution would be best. You can build one as follows: - add BIN_DIST=1 to mk/build.mk - make clean; make - make binary-dist Project=Ghc - tar cvzf ghc-6.4.1-x86_64-unknown-freebsd.tar.gz ghc-* the unreg reg hc-bundles are also useful. 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 port progress
On 24 October 2005 19:04, Wilhelm B. Kloke wrote: Wilhelm B. Kloke [EMAIL PROTECTED] schrieb: Simon Marlow [EMAIL PROTECTED] schrieb: Are you building GHC in a fresh tree now? I'd recommend doing that. Now I am using a *really* fresh tree. Formerly the compilation of Apply.cmm did not render an instructive error message, just failed for some sort of memory access exception. Now I have: I have enabled freebsd in the mangler now. After installing with make install stage=1 the compiler compiles an .o and .hi file, but it does not find the libraries to link with for test.hs. Is it that it does not find the libraries, or does it find the libraries but still gets a bunch of undefined references? If the latter, then there could be an issue with the mangler. Try an 'nm' on libHSbase.a to see if the missing symbols are actually defined. 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 port progress
On 19 October 2005 20:41, Wilhelm B. Kloke wrote: Simon Marlow [EMAIL PROTECTED] schrieb: Are you building GHC in a fresh tree now? I'd recommend doing that. Now I am using a *really* fresh tree. Formerly the compilation of Apply.cmm did not render an instructive error message, just failed for some sort of memory access exception. Now I have: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -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 parallel/RBH.c -o parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -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 Apply.cmm -o Apply.o ghc-asm: don't know how to mangle assembly language for: x86_64-unknown-freebsd Uhuh. This means that GHC is attempting to build a registerised version (which is what happens by default). If you don't plan to work on registerised support right now, you could set 'GhcUnregisterised=YES' in mk/build.mk. 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 port progress
On 20 October 2005 10:35, Simon Marlow wrote: On 19 October 2005 20:41, Wilhelm B. Kloke wrote: Simon Marlow [EMAIL PROTECTED] schrieb: Are you building GHC in a fresh tree now? I'd recommend doing that. Now I am using a *really* fresh tree. Formerly the compilation of Apply.cmm did not render an instructive error message, just failed for some sort of memory access exception. Now I have: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -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 parallel/RBH.c -o parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -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 Apply.cmm -o Apply.o ghc-asm: don't know how to mangle assembly language for: x86_64-unknown-freebsd Uhuh. This means that GHC is attempting to build a registerised version (which is what happens by default). If you don't plan to work on registerised support right now, you could set 'GhcUnregisterised=YES' in mk/build.mk. Incedentally, registerised support should be quite easy, since I've already done it for x86_64-unknown-linux, where the ABI and toolchain are the same AFAIK, so it might just be a case of enabling x86_64-unknown-freebsd in the right places (ghc-asm.lprl for one, I can't remember if there's anywhere else off hand). 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 port progress
On 18 October 2005 20:26, Wilhelm B. Kloke wrote: Simon Marlow [EMAIL PROTECTED] schrieb: At this point you can either do 'make install stage=1', or you can just use the compiler you built to build a clean GHC in another tree, i.e. with ./configure --with-ghc=/path/to/bootstrap/ghc/compiler/ghc-inplace. Now I am getting the following really strange error message: ==fptools== gmake all -wr; in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler/ghc-inplace -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -istage1/ghci -Istage1 -DGHCI -package template-haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include hschooks.h' -i../lib/compat -ignore-package Cabal -H80m -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi stage1/prelude/PrimOp.hi prelude/PrimOp.lhs:104:0: parse error (possibly incorrect indentation) ghc: 30809992 bytes, 2 GCs, 129776/129776 avg/max bytes residency (1 samples), 60M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.10 elapsed), 0.01 GC (0.02 elapsed) :ghc gmake[2]: *** [stage1/prelude/PrimOp.o] Fehler 1 gmake[1]: *** [install] Fehler 1 gmake[1]: Leaving directory `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc' gmake: *** [install] Fehler 1 I checked that PrimOp.lhs is identical with the versions in -i386amd64 and -amd64, so the error message text is certainly misleading. PrimOp.lhs includes a bunch of files that are auto-generated from primops.txt. In ghc/compiler you should have a bunch of files called primop-*-incl, which are generated by the genprimopcode program in ghc/utils/genprimopcode. If these files are empty or corrupt, just remove them and re-build. Are you building GHC in a fresh tree now? I'd recommend doing that. 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 port progress
Simon Marlow [EMAIL PROTECTED] schrieb: Are you building GHC in a fresh tree now? I'd recommend doing that. Now I am using a *really* fresh tree. Formerly the compilation of Apply.cmm did not render an instructive error message, just failed for some sort of memory access exception. Now I have: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -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 parallel/RBH.c -o parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -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 Apply.cmm -o Apply.o ghc-asm: don't know how to mangle assembly language for: x86_64-unknown-freebsd gmake[2]: *** [Apply.o] Fehler 1 gmake[1]: *** [all] Fehler 1 gmake[1]: Leaving directory `/data/home/wb/Haskell/ghc-6.4.1-amd64/ghc' gmake: *** [build] Fehler 1 I am looking myself how to add this info, but quick help by an informed person is welcome, too, as usual. -- 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 port progress
On 17 October 2005 19:19, Wilhelm B. Kloke wrote: Simon Marlow [EMAIL PROTECTED] schrieb: On 15 October 2005 23:10, Wilhelm B. Kloke wrote: 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? Yes. Sorry for any confusion. The happy error messages was an easy one, because I have a working 32bit happy on the system. But ghc-inplace seems to work pretty good now on amd64. I reached the end of hc-build successfully. Now there is a new problem. I tried (as root) make install at this point. This fails with error messages related to missing stage2 subdirectories. So I tried At this point you can either do 'make install stage=1', or you can just use the compiler you built to build a clean GHC in another tree, i.e. with ./configure --with-ghc=/path/to/bootstrap/ghc/compiler/ghc-inplace. gmake stage=2 boot This fails with messages ... cmm/CmmLex.hs:28: unterminated #if cmm/CmmLex.hs:20: unterminated #if ghc: 55123864 bytes, 6 GCs, 160600/160600 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.41 elapsed), 0.01 GC (0.05 elapsed) :ghc gmake: *** [depend] Fehler 1 This error is due to indented preprocessor lines #else #endif I've never seen this one before - very odd. You must have Alex in order to process CmmLex.x into CmmLex.hs, or did you copy this from the host tree? I just checked and a copy of CmmLex.hs from my build tree doesn't have any indented preprocessor directives. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC-6.4.1 on FreeBSD-amd64 port progress
Simon Marlow [EMAIL PROTECTED] schrieb: On 15 October 2005 23:10, Wilhelm B. Kloke wrote: 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? Yes. Sorry for any confusion. The happy error messages was an easy one, because I have a working 32bit happy on the system. But ghc-inplace seems to work pretty good now on amd64. I reached the end of hc-build successfully. Now there is a new problem. I tried (as root) make install at this point. This fails with error messages related to missing stage2 subdirectories. So I tried gmake stage=2 boot This fails with messages ... cmm/CmmLex.hs:28: unterminated #if cmm/CmmLex.hs:20: unterminated #if ghc: 55123864 bytes, 6 GCs, 160600/160600 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.41 elapsed), 0.01 GC (0.05 elapsed) :ghc gmake: *** [depend] Fehler 1 This error is due to indented preprocessor lines #else #endif I removed the indentation of these 2 lines. Then this file compiled, but there are more of them, the next being parser/Lexer.hs Is there a recommended way to handle this? -- 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
