RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86 or x86-64)
On 23 February 2005 11:01, Brian Strand wrote:
Thanks a lot! For anyone who runs into the same problem, here is what I did:
1. Converted to an rpm via "alien -r ghc6_6.2.2-3_amd64.deb" 2. Installed the resulting rpm. 3. When I tried to run ghc6, I got
/usr/lib/ghc-6.2.2 # /usr/bin/ghc6 ghc-6.2.2: Can't find package.conf as /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace
Other similar errors cropped up while trying to bootstrap. So, some crude symlink hackery:
cd /usr/lib/ghc-6.2.2 ln -s . ghc ln -s . driver ln -s package.conf.shipped package.conf.inplace # now we have a /usr/lib/ghc-6.2.2/ghc/driver/package.conf.inplace
mkdir utils ln -s .. utils/unlit # now we have a /usr/lib/ghc-6.2.2/utils/unlit/unlit
ln -s ghc6 /usr/bin/ghc # so ./configure finds ghc
This has gotten me quite a ways into the 6.2.2 compile; I'm still waiting to see if it completes successfully.
Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Cheers, Simon
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one.
Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ------------------------------------------------------------------------ ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs <<ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc>> make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture <<ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc>> ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo "INPUT(" *.o ")" >>ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
bstrand:
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one.
Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye:
==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ------------------------------------------------------------------------ ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs <<ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc>> make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture <<ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc>> ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo "INPUT(" *.o ")" >>ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the "diabolical splitter" from now on.) -- Don
[...] warning: don't know how to split object files on this architecture [...]
Wolfgang, Ryan - that looks like a splitter problem, no?
Definitely. Looks like there is no splitter for x86-64. SplitObjs=NO is definitely required.
(The splitter is more of a dark art than the evil mangler, I propose we name it the "diabolical splitter" from now on.)
Hmmm, even 'diabolical' doesn't quite seem to capture it. While the Evil Mangler is Evil, it is not Entirely Evil. We have to ask ourselves, what would the world be like without the Evil Mangler? Can there be Good without Evil? Would the Noble Code Generator (NCG) still be Noble if there were no Evil Mangler? The Evil Mangler is the kind of Evil that still has honor. Years after the forces of Good have finally prevailed, the broken remains of the Evil Mangler will still be proudly displayed in the castle's repositories, and the descendants of the Knights who overcame It will utter Its name with respect for an honoured adversary. The Satanic Splitter however, or whatever that Nameless Nemesis should be called, is an enemy of a different kind. Instead of attacking directly and honestly, it relies on treachery to destroy its foes. It lurks in the shadow of its big brother, the Evil Mangler, and it seeks to make the unsuspecting world believe that it is relatively benign. It does nothing that is essential to The Cause, and it tells its unsuspecting victims that can say SplitObjs=NO at any time, but when they do, it punishes them with multi-megabyte executables. And it cannot even do its evil deeds by itself - without the help of a Traitor in the code generator who puts "split markers" into the Code, the Splitter would be helpless. And I'm quite convinced that the Splitter's agents infiltrated Apple to make sure that the dead-stripping code in Apple's linker runs really slow. If Apple's code was efficient, the Splitter would already be banished from the Land of Apples. So go ahead and call the Splitter any bad names you like :-). Cheers, Wolfgang
Donald Bruce Stewart wrote:
bstrand:
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one.
Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye:
==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ------------------------------------------------------------------------ ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs <<ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc>> make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture <<ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc>> ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo "INPUT(" *.o ")" >>ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
Can you try building with SplitObjs=NO ?
Wolfgang, Ryan - that looks like a splitter problem, no?
(The splitter is more of a dark art than the evil mangler, I propose we name it the "diabolical splitter" from now on.)
-- Don
Using SplitObjs=NO gives out many warnings then finally dies with: ../../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 -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.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 StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Brian
bstrand:
Donald Bruce Stewart wrote:
bstrand:
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one.
Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye:
==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ------------------------------------------------------------------------ ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs <<ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc>> make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture <<ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc>> ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo "INPUT(" *.o ")" >>ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
Can you try building with SplitObjs=NO ?
Wolfgang, Ryan - that looks like a splitter problem, no?
(The splitter is more of a dark art than the evil mangler, I propose we name it the "diabolical splitter" from now on.)
-- Don
Using SplitObjs=NO gives out many warnings then finally dies with:
../../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 -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.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 StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
Are you building unregisterised? Those messages about global register variables (I think) imply that you are not -- and we haven't yet got x86_64 (terrible name, I much prefer amd64) registerised. Looks like you might even have found the point where registerisation breaks. Try building unregisterised: GhcUnregisterised=YES just as the .hc bootstrap compiler was built. -- Don
Donald Bruce Stewart wrote:
bstrand:
Donald Bruce Stewart wrote:
bstrand:
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one.
Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye:
==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ------------------------------------------------------------------------ ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs <<ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc>> make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture <<ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc>> ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo "INPUT(" *.o ")" >>ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
Can you try building with SplitObjs=NO ?
Wolfgang, Ryan - that looks like a splitter problem, no?
(The splitter is more of a dark art than the evil mangler, I propose we name it the "diabolical splitter" from now on.)
-- Don
Using SplitObjs=NO gives out many warnings then finally dies with:
../../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 -H64m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#includeSchedule.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 StgCRun.c -o StgCRun.o In file included from ../includes/Stg.h:149, from StgCRun.c:67: ../includes/Regs.h:213: warning: call-clobbered register used for global register variable ../includes/Regs.h:342: warning: call-clobbered register used for global register variable /tmp/ghc13908.s: Assembler messages: /tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp' make[2]: *** [StgCRun.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1
Are you building unregisterised? Those messages about global register variables (I think) imply that you are not -- and we haven't yet got x86_64 (terrible name, I much prefer amd64) registerised. Looks like you might even have found the point where registerisation breaks.
Try building unregisterised: GhcUnregisterised=YES
just as the .hc bootstrap compiler was built.
-- Don
Well, I don't know much about how the bootstrap compiler was built (I just downloaded it from http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6...), but building with GhcUnregisterised=YES and SplitObjs=NO died with: ==fptools== make all -wr; in /home/bstrand/src/ghc-6.4.20050224/libraries/base ------------------------------------------------------------------------ ../../ghc/compiler/ghc-inplace -H16m -O -H64m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi ghc-6.4.20050224: internal error: getMBlock: mmap: Invalid argument Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ make[2]: *** [GHC/Base.o] Error 254 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/libraries' make: *** [build] Error 1 Brian
participants (4)
-
Brian Strand -
dons＠cse.unsw.edu.au -
Simon Marlow -
Wolfgang Thaller