Circular dependency between the compiler and TH?
Apparently, pkString is part of TH.Syntax which is part of ./ libraries/template-haskell/Language/Haskell/TH/Syntax.hs. This does not get built after the compiler is built but the compiler depends on it in compiler/hsSyn/Convert.lhs. How do I resolve this? -- http://wagerlabs.com/
I can't tell just what you are doing, but somehow you seem to be building a stage-2 compiler in stage1. Furthermore, consider your invocation /usr/local/bin/ghc -H16m -O ... utils/Digraph.lhs ... utils/Digraph.lhs:133:12: Ambiguous occurrence `indices' It could refer to either `GHC.Arr.indices', imported from Array at utils/Digraph.lhs:43:0-11 or `Data.Array.Base.indices', imported from Data.Array.ST at utils/Digraph.lhs:48:0-19 I think this can only happen if /usr/local/bin/ghc is a version of GHC built by you, with the libraries chosen on a bad day. (There was a day or two when the libraries had to modules both exporting 'indices'.) Are you 100% sure that /usr/local/bin/ghc is a standard download? Are you 100% sure that you are fully up to date, in *all* packages (especially libraries/base and ghc itself). If so, I can only suggest starting in a fresh tree. Simon M is back on Monday and can help. But certainly something odd is going on in your build. Simoin | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Joel Reymont | Sent: 19 August 2006 08:45 | To: GHC users | Subject: Circular dependency between the compiler and TH? | | Apparently, pkString is part of TH.Syntax which is part of ./ | libraries/template-haskell/Language/Haskell/TH/Syntax.hs. This does | not get built after the compiler is built but the compiler depends on | it in compiler/hsSyn/Convert.lhs. | | How do I resolve this? | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Aug 19, 2006, at 7:30 PM, Simon Peyton-Jones wrote:
I can't tell just what you are doing, but somehow you seem to be building a stage-2 compiler in stage1.
Well, I'm on Mac Intel so I can only build ghc 6.5 using ghc 6.5. The one in /usr/local was built a few weeks ago and worked at the time. It's more than just the indices issue, this one can be solved by unpulling the patch. There are other issues with TH.Syntax.pkgString which I don't have in /usr/local and there are issues with another bit of TH. I don't think I'm doing anything wrong. I think it's a stage1 compiler too. /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -c hsSyn/Convert.lhs -o stage1/hsSyn/Convert.o -ohi stage1/hsSyn/Convert.hi /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -c typecheck/ TcMType.lhs -o stage1/typecheck/TcMType.o -ohi stage1/typecheck/ TcMType.hi /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -c main/TidyPgm.lhs - o stage1/main/TidyPgm.o -ohi stage1/main/TidyPgm.hi hsSyn/Convert.lhs:625:32: Not in scope: `TH.pkgString' <<ghc: 49771588 bytes, 8 GCs, 2578002/5045464 avg/max bytes residency (2 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.10 MUT (0.27 elapsed), 0.08 GC (0.13 elapsed) :ghc>> So I fix this line to use unpackPS instead of pkgString, after adjusting imports: mk_pkg pkg = stringToPackageId (TH.pkgString pkg) Now I get: hsSyn/Convert.lhs:574:23: Constructor `NameG' should have 2 arguments, but has been given 3 In the pattern: NameG th_ns pkg mod In the definition of `thRdrName': thRdrName ctxt_ns occ (NameG th_ns pkg mod) = (mkOrig $! (mkModule (mk_pkg pkg) (mk_mod mod))) $! (mk_occ (mk_ghc_ns th_ns) occ) -- http://wagerlabs.com/
Joel, I feel your pain. In my (very short) experience, the ghc build system can be fragile and impredictable some times. Randomly, it will decide to do a stage2 build in stage1, and this is clearly your case today Joel. The issue with indices and bounds is an actual issue, but can be solved easily by manually editing the affected file and fully qualifying the usages of said functions. That if it has not been fixed already. The issues with pkgString and NameG in Convert are due to building Convert.hs in stage1. In my system Convert.hs gets included in stage2 only. I am building ghc-6.5 head with all the patches. Since I am on Mac Intel too and bootstraping ghc-6.5 with the ghc-65 build from audreyT, I can assure you that there is nothing inherently wrong in this setup that prevents the current ghc-65 from building. Make sure that you have pulled the patches in all the libraries repositories too. If those get out of sync, ghc-65 will probably fail to build. Do a './darcs-all pull' always instead of a simple darcs pull. Finally, I recommend the brute force combo: ' make distclean ; autoreconf ; ./configure ; make -j2 ' If after that you see -DGHCI -DBREAKPOINT in your stage1 build, that's bad. Cheers pepe On 19/08/2006, at 20:56, Joel Reymont wrote:
On Aug 19, 2006, at 7:30 PM, Simon Peyton-Jones wrote:
I can't tell just what you are doing, but somehow you seem to be building a stage-2 compiler in stage1.
Well, I'm on Mac Intel so I can only build ghc 6.5 using ghc 6.5. The one in /usr/local was built a few weeks ago and worked at the time. It's more than just the indices issue, this one can be solved by unpulling the patch.
There are other issues with TH.Syntax.pkgString which I don't have in /usr/local and there are issues with another bit of TH. I don't think I'm doing anything wrong. I think it's a stage1 compiler too.
/usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell -threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -c hsSyn/ Convert.lhs -o stage1/hsSyn/Convert.o -ohi stage1/hsSyn/Convert.hi /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell -threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -c typecheck/ TcMType.lhs -o stage1/typecheck/TcMType.o -ohi stage1/typecheck/ TcMType.hi /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell -threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -c main/ TidyPgm.lhs -o stage1/main/TidyPgm.o -ohi stage1/main/TidyPgm.hi
hsSyn/Convert.lhs:625:32: Not in scope: `TH.pkgString' <<ghc: 49771588 bytes, 8 GCs, 2578002/5045464 avg/max bytes residency (2 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.10 MUT (0.27 elapsed), 0.08 GC (0.13 elapsed) :ghc>>
So I fix this line to use unpackPS instead of pkgString, after adjusting imports:
mk_pkg pkg = stringToPackageId (TH.pkgString pkg)
Now I get:
hsSyn/Convert.lhs:574:23: Constructor `NameG' should have 2 arguments, but has been given 3 In the pattern: NameG th_ns pkg mod In the definition of `thRdrName': thRdrName ctxt_ns occ (NameG th_ns pkg mod) = (mkOrig $! (mkModule (mk_pkg pkg) (mk_mod mod))) $! (mk_occ (mk_ghc_ns th_ns) occ)
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Aug 19, 2006, at 8:46 PM, Pepe Iborra wrote:
Finally, I recommend the brute force combo: ' make distclean ; autoreconf ; ./configure ; make -j2 ' If after that you see -DGHCI -DBREAKPOINT in your stage1 build, that's bad.
This is how I started yesterday. I repeated that just now, see -DGHCI and -DBREAKPOINT in the command line: /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -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 "cutils.h"' -i../compat -ignore-package Cabal -fglasgow-exts -c utils/Digraph.lhs -o stage1/utils/Digraph.o -ohi stage1/utils/ Digraph.hi -- http://wagerlabs.com/
Pepe Iborra wrote:
Joel, I feel your pain. In my (very short) experience, the ghc build system can be fragile and impredictable some times. Randomly, it will decide to do a stage2 build in stage1, and this is clearly your case today Joel.
GHC builds with GHCi support in stage1 if it decides that your installed GHC is exactly the same version as the one you're building, which should be safe. However, given the difficulties people occasionally have with this, I think I'll disable this particular "feature". Cheers, Simon
Joel Reymont wrote:
On Aug 19, 2006, at 7:30 PM, Simon Peyton-Jones wrote:
I can't tell just what you are doing, but somehow you seem to be building a stage-2 compiler in stage1.
Well, I'm on Mac Intel so I can only build ghc 6.5 using ghc 6.5.
You'd probably find it easier to use the source snapshots, since these will have dated version numbers (eg. 6.5.20060821 rather than just 6.5). GHC is trying to build GHCI in stage 1, because it thinks you have a compatible compiler. In fact, you have a slightly older 6.5 installed. However (as I think I mentioned before) we don't officially support building GHC using a random snapshot, because it would be impractical to do so. I understand why you can't use a released version in this case, though. As a workaround, you can 'make GhcWithInterpreter=NO' in compiler/ when building stage 1. Cheers, Simon
On Aug 21, 2006, at 4:10 PM, Simon Marlow wrote:
GHC is trying to build GHCI in stage 1, because it thinks you have a compatible compiler. In fact, you have a slightly older 6.5 installed. However (as I think I mentioned before) we don't officially support building GHC using a random snapshot, because it would be impractical to do so.
I'm not sure I understand this. How do you guys work then? Do you always build ghc 6.5 using ghc 6.4? What about the time-honored technique of bootstrapping using yourself?
As a workaround, you can 'make GhcWithInterpreter=NO' in compiler/ when building stage 1.
Still doesn't build after make clean in compiler and then a no-ghci make: /usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen - InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc- timing -H16M '-#include "cutils.h"' -i../compat -ignore-package Cabal -c ghci/ByteCodeAsm.lhs -o stage1/ghci/ByteCodeAsm.o -ohi stage1/ghci/ByteCodeAsm.hi ghci/ByteCodeAsm.lhs:20:0: Failed to load interface for `ByteCodeInstr': Could not find module `ByteCodeInstr': use -v to see a list of the files searched for <<ghc: 23420660 bytes, 4 GCs, 111664/111664 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.04 MUT (0.15 elapsed), 0.02 GC (0.03 elapsed) :ghc>> -- http://wagerlabs.com/
Joel Reymont wrote:
On Aug 21, 2006, at 4:10 PM, Simon Marlow wrote:
GHC is trying to build GHCI in stage 1, because it thinks you have a compatible compiler. In fact, you have a slightly older 6.5 installed. However (as I think I mentioned before) we don't officially support building GHC using a random snapshot, because it would be impractical to do so.
I'm not sure I understand this. How do you guys work then? Do you always build ghc 6.5 using ghc 6.4?
Sure.
What about the time-honored technique of bootstrapping using yourself?
You can do that of course, but it has to be the *exact same compiler*. That is, not one you built from last week's sources. It's just not practical to support building GHC with any GHC that existed at any point in the past, we'd have #ifdefs up the wazoo and a testing nightmare.
As a workaround, you can 'make GhcWithInterpreter=NO' in compiler/ when building stage 1.
Still doesn't build after make clean in compiler and then a no-ghci make:
/usr/local/bin/ghc -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/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen - InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc- timing -H16M '-#include "cutils.h"' -i../compat -ignore-package Cabal -c ghci/ByteCodeAsm.lhs -o stage1/ghci/ByteCodeAsm.o -ohi stage1/ghci/ByteCodeAsm.hi
ghci/ByteCodeAsm.lhs:20:0: Failed to load interface for `ByteCodeInstr': Could not find module `ByteCodeInstr': use -v to see a list of the files searched for <<ghc: 23420660 bytes, 4 GCs, 111664/111664 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.04 MUT (0.15 elapsed), 0.02 GC (0.03 elapsed) :ghc>>
It's still trying to build part of GHCi. Try cleaning harder (make distclean), or just start with a fresh tree. Also I just fixed compiler/Makefile so it won't try to build GHCi in stage1, even if it thinks you are bootstrapping with the same GHC version. Cheers, Simon
On Aug 21, 2006, at 5:03 PM, Simon Marlow wrote:
It's still trying to build part of GHCi. Try cleaning harder (make distclean), or just start with a fresh tree. Also I just fixed compiler/Makefile so it won't try to build GHCi in stage1, even if it thinks you are bootstrapping with the same GHC version.
I just did a make clean at the top and pulled all patches but for the Fix Arrays one. ghc has been building for a while which I take is a good sign. -- http://wagerlabs.com/
Hello Simon, Monday, August 21, 2006, 8:03:41 PM, you wrote:
I'm not sure I understand this. How do you guys work then? Do you always build ghc 6.5 using ghc 6.4?
Sure.
What about the time-honored technique of bootstrapping using yourself?
You can do that of course, but it has to be the *exact same compiler*. That is, not one you built from last week's sources. It's just not practical to support building GHC with any GHC that existed at any point in the past, we'd have #ifdefs up the wazoo and a testing nightmare.
btw, it's not obvious on first look, nor mentioned in building docs. i propose to add your comment there -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Simon,
Monday, August 21, 2006, 8:03:41 PM, you wrote:
You can do that of course, but it has to be the *exact same compiler*. That is, not one you built from last week's sources. It's just not practical to support building GHC with any GHC that existed at any point in the past, we'd have #ifdefs up the wazoo and a testing nightmare.
btw, it's not obvious on first look, nor mentioned in building docs. i propose to add your comment there
Strange, I did think it was documented, but I can't find it. Thanks for pointing it out, I'll add something to the docs. Cheers, Simon
I get to stage two and then this: ghci/InteractiveUI.hs:74:7: Could not find module `System.Console.Readline': Use -v to see a list of the files searched for. <<ghc: 302864492 bytes, 43 GCs, 4361258/9612180 avg/max bytes residency (4 samples), 24M in use, 0.01 INIT (0.00 elapsed), 0.79 MUT (11.30 elapsed), 0.13 GC (0.15 elapsed) :ghc>> What do I do? touch .depend-BASE ../compiler/ghc-inplace -M -optdep-f -optdep.depend-BASE -osuf o - I../includes -H16m -O -iutils -ibasicTypes -itypes -ihsSyn - iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise - isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -icmm -inativeGen -ighci - Istage2 -DGHCI -DBREAKPOINT -package template-haskell -threaded - package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics - Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name ghc-6.5.20060820 -fgenerics basicTypes/ BasicTypes.lhs basicTypes/DataCon.lhs basicTypes/Demand.lhs basicTypes/Id.lhs basicTypes/IdInfo.lhs basicTypes/Literal.lhs basicTypes/MkId.lhs basicTypes/Module.lhs basicTypes/Name.lhs basicTypes/NameEnv.lhs basicTypes/NameSet.lhs basicTypes/ NewDemand.lhs basicTypes/OccName.lhs basicTypes/RdrName.lhs basicTypes/SrcLoc.lhs basicTypes/UniqSupply.lhs basicTypes/Unique.lhs basicTypes/Var.lhs basicTypes/VarEnv.lhs basicTypes/VarSet.lhs cmm/ CLabel.hs cmm/Cmm.hs cmm/CmmLex.hs cmm/CmmLint.hs cmm/CmmOpt.hs cmm/ CmmParse.hs cmm/CmmUtils.hs cmm/MachOp.hs cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs codeGen/CgBindery.lhs codeGen/CgCallConv.hs codeGen/ CgCase.lhs codeGen/CgClosure.lhs codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/CgForeignCall.hs codeGen/CgHeapery.lhs codeGen/CgInfoTbls.hs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/CgParallel.hs codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/CgStackery.lhs codeGen/ CgTailCall.lhs codeGen/CgTicky.hs codeGen/CgUtils.hs codeGen/ ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/SMRep.lhs coreSyn/ CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/CorePrep.lhs coreSyn/ CoreSubst.lhs coreSyn/CoreSyn.lhs coreSyn/CoreTidy.lhs coreSyn/ CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ExternalCore.lhs coreSyn/ MkExternalCore.lhs coreSyn/PprCore.lhs coreSyn/PprExternalCore.lhs cprAnalysis/CprAnalyse.lhs deSugar/Check.lhs deSugar/Desugar.lhs deSugar/DsArrows.lhs deSugar/DsBinds.lhs deSugar/DsCCall.lhs deSugar/ DsExpr.lhs deSugar/DsForeign.lhs deSugar/DsGRHSs.lhs deSugar/ DsListComp.lhs deSugar/DsMeta.hs deSugar/DsMonad.lhs deSugar/ DsUtils.lhs deSugar/Match.lhs deSugar/MatchCon.lhs deSugar/ MatchLit.lhs ghci/ByteCodeAsm.lhs ghci/ByteCodeFFI.lhs ghci/ ByteCodeGen.lhs ghci/ByteCodeInstr.lhs ghci/ByteCodeItbls.lhs ghci/ ByteCodeLink.lhs ghci/InteractiveUI.hs ghci/Linker.lhs ghci/ ObjLink.lhs hsSyn/Convert.lhs hsSyn/HsBinds.lhs hsSyn/HsDecls.lhs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs hsSyn/HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs iface/IfaceEnv.lhs iface/IfaceSyn.lhs iface/ IfaceType.lhs iface/LoadIface.lhs iface/MkIface.lhs iface/TcIface.lhs main/CmdLineParser.hs main/CodeOutput.lhs main/Config.hs main/ Constants.lhs main/DriverMkDepend.hs main/DriverPhases.hs main/ DriverPipeline.hs main/DynFlags.hs main/ErrUtils.lhs main/Finder.lhs main/GHC.hs main/HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs main/HscTypes.lhs main/Main.hs main/PackageConfig.hs main/ Packages.lhs main/ParsePkgConf.hs main/PprTyThing.hs main/ StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs nativeGen/ AsmCodeGen.lhs nativeGen/MachCodeGen.hs nativeGen/MachInstrs.hs nativeGen/MachRegs.lhs nativeGen/NCGMonad.hs nativeGen/ PositionIndependentCode.hs nativeGen/PprMach.hs nativeGen/ RegAllocInfo.hs nativeGen/RegisterAlloc.hs ndpFlatten/FlattenInfo.hs ndpFlatten/FlattenMonad.hs ndpFlatten/Flattening.hs ndpFlatten/ NDPCoreUtils.hs ndpFlatten/PArrAnal.hs parser/Ctype.lhs parser/ LexCore.hs parser/Lexer.hs parser/Parser.hs parser/ParserCore.hs parser/ParserCoreUtils.hs parser/RdrHsSyn.lhs prelude/ForeignCall.lhs prelude/PrelInfo.lhs prelude/PrelNames.lhs prelude/PrelRules.lhs prelude/PrimOp.lhs prelude/TysPrim.lhs prelude/TysWiredIn.lhs profiling/CostCentre.lhs profiling/SCCfinal.lhs rename/RnBinds.lhs rename/RnEnv.lhs rename/RnExpr.lhs rename/RnHsSyn.lhs rename/ RnNames.lhs rename/RnSource.lhs rename/RnTypes.lhs simplCore/CSE.lhs simplCore/FloatIn.lhs simplCore/FloatOut.lhs simplCore/ LiberateCase.lhs simplCore/OccurAnal.lhs simplCore/SAT.lhs simplCore/ SATMonad.lhs simplCore/SetLevels.lhs simplCore/SimplCore.lhs simplCore/SimplEnv.lhs simplCore/SimplMonad.lhs simplCore/ SimplUtils.lhs simplCore/Simplify.lhs simplStg/SRT.lhs simplStg/ SimplStg.lhs simplStg/StgStats.lhs specialise/Rules.lhs specialise/ SpecConstr.lhs specialise/Specialise.lhs stgSyn/CoreToStg.lhs stgSyn/ StgLint.lhs stgSyn/StgSyn.lhs stranal/DmdAnal.lhs stranal/ SaAbsInt.lhs stranal/SaLib.lhs stranal/StrictAnal.lhs stranal/ WorkWrap.lhs stranal/WwLib.lhs typecheck/Inst.lhs typecheck/ TcArrows.lhs typecheck/TcBinds.lhs typecheck/TcClassDcl.lhs typecheck/ TcDefaults.lhs typecheck/TcDeriv.lhs typecheck/TcEnv.lhs typecheck/ TcExpr.lhs typecheck/TcForeign.lhs typecheck/TcGenDeriv.lhs typecheck/ TcHsSyn.lhs typecheck/TcHsType.lhs typecheck/TcInstDcls.lhs typecheck/ TcMType.lhs typecheck/TcMatches.lhs typecheck/TcPat.lhs typecheck/ TcRnDriver.lhs typecheck/TcRnMonad.lhs typecheck/TcRnTypes.lhs typecheck/TcRules.lhs typecheck/TcSimplify.lhs typecheck/TcSplice.lhs typecheck/TcTyClsDecls.lhs typecheck/TcTyDecls.lhs typecheck/ TcType.lhs typecheck/TcUnify.lhs types/Class.lhs types/FunDeps.lhs types/Generics.lhs types/InstEnv.lhs types/Kind.lhs types/TyCon.lhs types/Type.lhs types/TypeRep.lhs types/Unify.lhs utils/Bag.lhs utils/ Binary.hs utils/BitSet.lhs utils/BufWrite.hs utils/Digraph.lhs utils/ Encoding.hs utils/FastMutInt.lhs utils/FastString.lhs utils/ FastTypes.lhs utils/FiniteMap.lhs utils/IOEnv.hs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs utils/Outputable.lhs utils/ Panic.lhs utils/Pretty.lhs utils/StringBuffer.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs ghci/InteractiveUI.hs:74:7: Could not find module `System.Console.Readline': Use -v to see a list of the files searched for. <<ghc: 302864492 bytes, 43 GCs, 4361258/9612180 avg/max bytes residency (4 samples), 24M in use, 0.01 INIT (0.00 elapsed), 0.79 MUT (11.30 elapsed), 0.13 GC (0.15 elapsed) :ghc>> make[2]: *** [depend] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 -- http://wagerlabs.com/
Joel Reymont wrote:
I get to stage two and then this:
ghci/InteractiveUI.hs:74:7: Could not find module `System.Console.Readline': Use -v to see a list of the files searched for. <<ghc: 302864492 bytes, 43 GCs, 4361258/9612180 avg/max bytes residency (4 samples), 24M in use, 0.01 INIT (0.00 elapsed), 0.79 MUT (11.30 elapsed), 0.13 GC (0.15 elapsed) :ghc>>
Was the readline package built? (it's in libraries/readline). Cheers, Simon
On 8/19/06, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
I can't tell just what you are doing, but somehow you seem to be building a stage-2 compiler in stage1.
On compiler/Makefile we got ifeq "$(BootingFromHc)" "YES" # HC files are always from a self-booted compiler bootstrapped = YES else ifneq "$(findstring $(stage), 2 3)" "" bootstrapped = YES else bootstrapped = $(shell if (test $(GhcCanonVersion) -eq $(ProjectVersionInt) -a $(GhcPatchLevel) -eq $(ProjectPatchLevel)); then echo YES; else echo NO; fi) endif endif Which would turn bootstrapped=YES when building 6.5 with 6.5, even during stage1. And then ifeq "$(GhcWithInterpreter) $(bootstrapped)" "YES YES" and inside this if it also turns template-haskell on. It's a bit funny. It makes sense for end user not to need bootstrap compiler more than once - for example to build new set of libraries for ghc would be much faster, and bootstrapping holds no additional value. So, Joel, you might want to change your mk/Config.mk and lie about your ghc version a bit (you need to mod the file after configure). Say it's 6.4, and you might not need to unpull patches and you might get normal 2-stage bootstrap. Best regards, --Esa
On Aug 19, 2006, at 8:48 PM, Esa Ilari Vuokko wrote:
So, Joel, you might want to change your mk/Config.mk and lie about your ghc version a bit (you need to mod the file after configure). Say it's 6.4, and you might not need to unpull patches and you might get normal 2-stage bootstrap.
Changed to 6.4. Still getting the bounds error. This is a freshly checked out tree, btw. -- http://wagerlabs.com/
On 8/19/06, Joel Reymont <joelr1@gmail.com> wrote:
On Aug 19, 2006, at 8:48 PM, Esa Ilari Vuokko wrote:
So, Joel, you might want to change your mk/Config.mk and lie about your ghc version a bit (you need to mod the file after configure). Say it's 6.4, and you might not need to unpull patches and you might get normal 2-stage bootstrap.
Changed to 6.4. Still getting the bounds error. This is a freshly checked out tree, btw.
Ergh, sorry. That'd be right, because that is controlled by preprocessor defs....you'll need to unpull that patch for stage1, but hopefully it won't try building ghci and template-haskell in stage1 this time. Best regards, --Esa
On Aug 19, 2006, at 9:25 PM, Esa Ilari Vuokko wrote:
Ergh, sorry. That'd be right, because that is controlled by preprocessor defs....you'll need to unpull that patch for stage1, but hopefully it won't try building ghci and template-haskell in stage1 this time.
No dice. Still getting the TH.pkgString issue. -- http://wagerlabs.com/
On Aug 19, 2006, at 8:48 PM, Esa Ilari Vuokko wrote:
So, Joel, you might want to change your mk/Config.mk and lie about your ghc version a bit (you need to mod the file after configure). Say it's 6.4, and you might not need to unpull patches and you might get normal 2-stage bootstrap.
The version change did not help. I also did ./darcs-all pull in my old ghc directory, the one I used to build my current /usr/local/bin/ ghc. Well, the results are the same. -DBREAKPOINT and -DGHCI present and build bombing out on array bounds, etc. -- http://wagerlabs.com/
participants (6)
-
Bulat Ziganshin -
Esa Ilari Vuokko -
Joel Reymont -
Pepe Iborra -
Simon Marlow -
Simon Peyton-Jones