Circular dependency between the compiler and TH?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Circular dependency between the compiler and TH?

Joel Reymont
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: Circular dependency between the compiler and TH?

Simon Peyton Jones
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: [hidden email]
[mailto:glasgow-haskell-users-
| [hidden email]] 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
| [hidden email]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Pepe Iborra-3
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)
>
>
> --
> http://wagerlabs.com/
>
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Esa Ilari Vuokko
In reply to this post by Simon Peyton Jones
On 8/19/06, Simon Peyton-Jones <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont
In reply to this post by Pepe Iborra-3

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Esa Ilari Vuokko
In reply to this post by Joel Reymont
On 8/19/06, Joel Reymont <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont
In reply to this post by Esa Ilari Vuokko

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont
In reply to this post by Esa Ilari Vuokko

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Simon Marlow-5
In reply to this post by Joel Reymont
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Simon Marlow-5
In reply to this post by Pepe Iborra-3
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont
In reply to this post by Simon Marlow-5

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Simon Marlow-5
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont

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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: Circular dependency between the compiler and TH?

Bulat Ziganshin-2
In reply to this post by Simon Marlow-5
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:[hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Joel Reymont
In reply to this post by Simon Marlow-5
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/





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Simon Marlow-5
In reply to this post by Bulat Ziganshin-2
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Circular dependency between the compiler and TH?

Simon Marlow-5
In reply to this post by Joel Reymont
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users