Can't compile GHC 6.8.2
I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the typechecker refuses to compile. The problem seems to be that the hi-boot files in compiler/typecheck contain some incorrect type signatures. I've fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As it stands, it says tcMatchesFun :: Name.Name -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) but it should say something like tcMatchesFun :: Name.Name -> Bool -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, so I tried saying Prelude.Bool instead. Now I get the complaint that Prelude.Bool isn't in scope. Has anyone else seen this issue? I've looked for answers in the docs and with Google, but no luck. I'm running Mac OS 10.3, with GHC 6.2 installed under Fink. I borrowed the Fink package for GHC 6.8.2 and adapted it slightly so it would bootstrap from my existing GHC, as the bootstrap code available for download relies on a later version of my OS. GHC 6.2 can't compile GHC 6.10, which is why I'm going for the earlier version. Cheers, Barney.
Barney Stratford wrote:
I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the typechecker refuses to compile. The problem seems to be that the hi-boot files in compiler/typecheck contain some incorrect type signatures. I've fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As it stands, it says
tcMatchesFun :: Name.Name -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId)
but it should say something like
tcMatchesFun :: Name.Name -> Bool -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId)
Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, so I tried saying Prelude.Bool instead. Now I get the complaint that Prelude.Bool isn't in scope.
Has anyone else seen this issue? I've looked for answers in the docs and with Google, but no luck.
I think we only supported using GHC 6.4 for building 6.8. Using 6.2 might be possible, but no guarantees. To answer your question above, you probably want GHC.Base.Bool (hi-boot files used to need "original names", that is, the module that originally defined a thing, which might be different from the module you normally get it from). Cheers, Simon
Ah hum. We probably have not compiled GHC 6.8 with 6.2 for some time. Worse, we don't even clearly document what the oldest version is that should bootstrap any given version. Ian: could you extend the building guide http://hackage.haskell.org/trac/ghc/wiki/Building (perhaps the "what tools you need" page?) with a) the algorithm we use. I think we say that any GHC can be compiled with the previous three major releases, but maybe it's two. b) a table giving the claimed state of play To compile You need at least 6.10 6.6 6.8 6.4 no need to go back too far. THanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Barney Stratford | Sent: 24 November 2008 11:27 | To: glasgow-haskell-users@haskell.org | Subject: Can't compile GHC 6.8.2 | | I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the | typechecker refuses to compile. The problem seems to be that the hi-boot | files in compiler/typecheck contain some incorrect type signatures. I've | fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As | it stands, it says | | tcMatchesFun :: Name.Name | -> HsExpr.MatchGroup Name.Name | -> TcType.BoxyRhoType | -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) | | but it should say something like | | tcMatchesFun :: Name.Name -> Bool | -> HsExpr.MatchGroup Name.Name | -> TcType.BoxyRhoType | -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) | | Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, | so I tried saying Prelude.Bool instead. Now I get the complaint that | Prelude.Bool isn't in scope. | | Has anyone else seen this issue? I've looked for answers in the docs and | with Google, but no luck. | | I'm running Mac OS 10.3, with GHC 6.2 installed under Fink. I borrowed | the Fink package for GHC 6.8.2 and adapted it slightly so it would | bootstrap from my existing GHC, as the bootstrap code available for | download relies on a later version of my OS. GHC 6.2 can't compile GHC | 6.10, which is why I'm going for the earlier version. | | Cheers, | Barney. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I can now confirm that 6.2 can, in fact, bootstrap 6.8.2 (with the corrections to those hi-boots), although I've still not got the build to complete. If anyone wants to see the patch file, then let me know and I'll send it when I've ironed out the last creases. Thanks to all those who helped out. Barney.
There's good news and bad news. The good news is that the compilation of my shiny almost-new GHC is complete. The bad news is, it won't link. It's grumbling about ld: /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: ___gmpn_cmp ___gmpn_gcd_1 ___gmpz_fdiv_qr ___gmpz_init ___gmpz_tdiv_qr ___gmpz_com ___gmpz_xor ___gmpz_ior ___gmpz_and ___gmpz_divexact ___gmpz_tdiv_r ___gmpz_tdiv_q ___gmpz_gcd ___gmpz_mul ___gmpz_sub ___gmpz_add Looking through the archives, it seems like this is an old favourite bug rearing its ugly head again. The suggested remedy of commenting out the line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as that line isn't there anyway. The manpage for ld has an option "-read_only_relocs warning" that looks like it might suppress this problem, but I don't fully understand what it's doing. What would you suggest? Cheers, Barney.
Hello, On Monday 24 November 2008 23:15, Barney Stratford wrote:
There's good news and bad news. The good news is that the compilation of my shiny almost-new GHC is complete. The bad news is, it won't link. It's grumbling about
ld: /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: ___gmpn_cmp ___gmpn_gcd_1 ___gmpz_fdiv_qr ___gmpz_init ___gmpz_tdiv_qr ___gmpz_com ___gmpz_xor ___gmpz_ior ___gmpz_and ___gmpz_divexact ___gmpz_tdiv_r ___gmpz_tdiv_q ___gmpz_gcd ___gmpz_mul ___gmpz_sub ___gmpz_add
Looking through the archives, it seems like this is an old favourite bug rearing its ugly head again. The suggested remedy of commenting out the line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as that line isn't there anyway. The manpage for ld has an option "-read_only_relocs warning" that looks like it might suppress this problem, but I don't fully understand what it's doing.
What would you suggest?
The heading seems to be: Your build is missing it's required GMP (GNU Multiple Precision) library which is used for the Haskell Integer type. Whether this information is enough to get you going again, I cannot tell, as I have no experience with your particular circumstances: There may be additional problems ahead getting this library installed and making sure that it gets referred from all the right places. But that seems to be the answer: Get GMP, install it, and make sure that linking and running Haskell code (not least GHC itself) have access.
Cheers, Barney. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Best regards Thorkil
The heading seems to be: Your build is missing it's required GMP (GNU Multiple Precision) library No, I have GMP installed, and it's correctly compiling against it. The issue isn't that these symbols are missing altogether, but rather that there's something wrong with them. It looks to me like it's identical to this bug afflicting 6.9: http://hackage.haskell.org/trac/ghc/ticket/2262
Cheers, Barney.
Hello, On Monday 24 November 2008 23:48, Barney Stratford wrote:
The heading seems to be: Your build is missing it's required GMP (GNU Multiple Precision) library No, I have GMP installed, and it's correctly compiling against it. The issue isn't that these symbols are missing altogether, but rather that there's something wrong with them. It looks to me like it's identical to this bug afflicting 6.9: http://hackage.haskell.org/trac/ghc/ticket/2262
Yes, you are right, I didn't address the real issue. Sorry, I don't really know what to do about this.
Cheers, Barney.
I notice, however, that the workaround for the issue that you referrred to (#2262) was to remove a line saying -fvia-C. That would, in most circumstances, be roughly the same as saying -fasm (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#...). I suggest that you look at http://hackage.haskell.org/trac/ghc/wiki/Building and in particular http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking for some inspiration. Best regards Thorkil
Barney Stratford wrote:
There's good news and bad news. The good news is that the compilation of my shiny almost-new GHC is complete. The bad news is, it won't link. It's grumbling about
ld: /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: ___gmpn_cmp ___gmpn_gcd_1 ___gmpz_fdiv_qr ___gmpz_init ___gmpz_tdiv_qr ___gmpz_com ___gmpz_xor ___gmpz_ior ___gmpz_and ___gmpz_divexact ___gmpz_tdiv_r ___gmpz_tdiv_q ___gmpz_gcd ___gmpz_mul ___gmpz_sub ___gmpz_add
Looking through the archives, it seems like this is an old favourite bug rearing its ugly head again. The suggested remedy of commenting out the line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as that line isn't there anyway. The manpage for ld has an option "-read_only_relocs warning" that looks like it might suppress this problem, but I don't fully understand what it's doing.
What would you suggest?
The workaround is almost certainly to build the RTS with -fasm. However, I'd be really pleased if someone could get to the bottom of this, so that we can fix the root cause. You can get a look at the .s file generated for PrimOps by saying $ cd rts $ make PrimOps.s (make sure you're still compiling via-C). Have a look at the references to those symbols, do they look suspicious at all? Try compiling the same module with -fasm, and compare the .s file with the via-C version. Also you could try poking around in the .o file with objdump, and see what relocation entries are being generated in both cases. Cheers, Simon
The workaround is almost certainly to build the RTS with -fasm. According to http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#..., -fasm is the default option anyway, or am I missing something here?
It looks like this is an issue with the way Apple's version of gcc works. The gmp people are complaining bitterly, saying not to use a Mac at all. Perhaps the real issue here is that I should get a new computer. This old lady's got a bit wrinkly, but there's life in her yet. Barney.
Barney Stratford wrote:
The workaround is almost certainly to build the RTS with -fasm. According to http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#..., -fasm is the default option anyway, or am I missing something here?
It looks like this is an issue with the way Apple's version of gcc works. The gmp people are complaining bitterly, saying not to use a Mac at all.
Do you have a link to something describing the problem? I didn't turn up anything that looked directly relevant, only this: http://gmplib.org/macos.html which seems to suggest that problems can be worked around with flags to gcc. We don't use -fno-pic. Cheers, Simon
Do you have a link to something describing the problem? This might be relevant: I don't know. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14612
Further useful information. The problem doesn't manifest itself when compiling GHC 6.6, so the question is what parts of the runtime system changed in the meantime. The changes to rts/Linker.c are just refactorings and addition of 64-bit support. The only other place I can see where those things are mentioned is in rts/PrimOps.cmm. In the meantime, I'll try using a later GCC and see if that helps (assuming I can compile it!). Barney.
The suggested remedy of commenting out the line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as that line isn't there anyway.
In case it is not obvious from what other people have said, way back in the days of ghc-6.2, you got -fvia-C by default, whether it was specified on the command-line or not. To override via-C, you needed to explicitly choose the opposite (-fasm). With more recent versions of the compiler, the default flipped over to -fasm. Regards, Malcolm
On Mon, Nov 24, 2008 at 12:28:28PM +0000, Simon Peyton-Jones wrote:
Ah hum. We probably have not compiled GHC 6.8 with 6.2 for some time. Worse, we don't even clearly document what the oldest version is that should bootstrap any given version.
Ian: could you extend the building guide http://hackage.haskell.org/trac/ghc/wiki/Building (perhaps the "what tools you need" page?) with
I've added something to http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites Thanks Ian
I have a workaround for the linker bugs that keep popping up under Mac OS X, and now have a working GHC 6.8. I found that saying -fasm didn't help matters. Instead, on the assumption that the linker gets it wrong and there is in fact nothing wrong with the object file, I applied these two patches: diff -u a/compiler/Makefile b/compiler/Makefile --- a/compiler/Makefile Mon Dec 10 18:11:32 2007 +++ b/compiler/Makefile Wed Nov 26 09:35:12 2008 @@ -753,7 +753,7 @@ $(SED) -e "s@GHC_PATH@$(GHC_PATH)@g" -e "s@TOP_ABS@$(FPTOOLS_TOP_ABS)@g" < $< > $@ $(INPLACE_PROG): $(INPLACE_SRC) - $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ + $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ -optl "-Wl,-read_only_relocs,warning" all :: $(INPLACE_PROG) diff -u a/mk/target.mk b/mk/target.mk --- a/mk/target.mk Mon Dec 10 18:11:31 2007 +++ b/mk/target.mk Thu Nov 27 12:14:02 2008 @@ -231,7 +231,7 @@ ifneq "$(BootingFromHc)" "YES" $(HS_PROG) :: $(OBJS) - $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) + $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) -optl "-Wl,-read_only_relocs,warning" else # see bootstrap.mk $(HS_PROG) :: $(OBJS) Another way to fix these problems would be to mumble something about -segprot __TEXT rwx rwx, but this is definitely a hack. I also had to patch Cabal so it ranlibs the libraries it creates (which is required under Mac OS), and fixed the .hi-boot files in compiler/typecheck. (Shouldn't these be updated automatically?) Without those changes, the typechecker won't typecheck. Oh, the irony! Perhaps someone that knows more about how the build system works could figure out the right way to do these things. Barney.
Barney Stratford wrote:
I have a workaround for the linker bugs that keep popping up under Mac OS X, and now have a working GHC 6.8. I found that saying -fasm didn't help matters. Instead, on the assumption that the linker gets it wrong and there is in fact nothing wrong with the object file, I applied these two patches:
diff -u a/compiler/Makefile b/compiler/Makefile --- a/compiler/Makefile Mon Dec 10 18:11:32 2007 +++ b/compiler/Makefile Wed Nov 26 09:35:12 2008 @@ -753,7 +753,7 @@ $(SED) -e "s@GHC_PATH@$(GHC_PATH)@g" -e "s@TOP_ABS@$(FPTOOLS_TOP_ABS)@g" < $< > $@
$(INPLACE_PROG): $(INPLACE_SRC) - $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ + $(HC) -cpp $(INPLACE_EXTRA_FLAGS) $< -o $@ -optl "-Wl,-read_only_relocs,warning"
all :: $(INPLACE_PROG)
diff -u a/mk/target.mk b/mk/target.mk --- a/mk/target.mk Mon Dec 10 18:11:31 2007 +++ b/mk/target.mk Thu Nov 27 12:14:02 2008 @@ -231,7 +231,7 @@
ifneq "$(BootingFromHc)" "YES" $(HS_PROG) :: $(OBJS) - $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) + $(HC) -o $@ $(HC_OPTS) $(LD_OPTS) $(OBJS) -optl "-Wl,-read_only_relocs,warning" else # see bootstrap.mk $(HS_PROG) :: $(OBJS)
Another way to fix these problems would be to mumble something about -segprot __TEXT rwx rwx, but this is definitely a hack.
I also had to patch Cabal so it ranlibs the libraries it creates (which is required under Mac OS), and fixed the .hi-boot files in compiler/typecheck. (Shouldn't these be updated automatically?) Without those changes, the typechecker won't typecheck. Oh, the irony!
Perhaps someone that knows more about how the build system works could figure out the right way to do these things.
Presumably you'll get the same error when using your new GHC to link any Haskell program? So in fact GHC itself should be adding this option when linking the RTS on this platform. The right place to add this would be in rts/package.conf.in, in extra-ld-opts, with suitable platform-specific #ifdefs. If you can whip up a patch and test it, I'll commit. Cheers, Simon
The right place to add this would be in rts/package.conf.in, in extra-ld- opts, with suitable platform-specific #ifdefs. If you can whip up a patch and test it, I'll commit. Here's the patch, which now compiles correctly.
diff -u a/rts/package.conf.in b/rts/package.conf.in --- a/rts/package.conf.in Mon Dec 10 18:11:32 2007 +++ b/rts/package.conf.in Thu Dec 11 09:36:54 2008 @@ -150,6 +150,10 @@ , "-u", "base_GHCziConc_ensureIOManagerIsRunning_closure" #endif +#ifdef darwin_HOST_OS + , "-read_only_relocs", "warning" +#endif + framework-dirs: #ifdef HAVE_FRAMEWORK_GMP Cheers, Barney.
Hello Barney & all, I've been following your messages with some interest, as I too have been trying to build a more-modern ghc on my G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and tried to build 6.8.3; I'm finally at the point where I have something to report, although I'm not sure if it's a success or a failure report... :-/ I applied your patch to package.conf.in (approximately; the relevant section wasn't quite identical), edited rts/Linker.c to add "#define LC_SEGMENT_64 LC_SEGMENT", and hacked up a wrapper script around ar to always ranlib the library being processed; you had mentioned patching cabal, but I decided the wrapper around ar was easier... a hack, but what the hell. After that, "configure && make" ran to completion without errors (although it took a couple of days, since I had all the extralibs). Success! ... or is it? I installed the new compiler into /usr/local, then tested it by trying "ghc -v". Alas, no joy! It died with some dynamic-link error which I've approximately reproduced here: lupus:~/ghc-6.8.3% ghc-6.8.3 -v dyld: relocation error (external relocation for symbol _pthread_mutex_unlock in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap Failure! ... or is it? I thought, how can this be?!? It built itself through stage2, it has to be good! But clearly it isn't... So I tried one last thing: I tried to use the stage1 compiler directly to compile the scheme interpreter I wrote nearly a year ago. That initially failed, too, but for a simple reason, and one I could work around: no readline in ghc 6.8.3. Once I changed the scheme interpreter to not use readline, it compiled, linked, and runs. So... success or failure? I'm really not quite sure... I guess I could try installing the stage1 compiler instead of the stage2 compiler, it seems that it might work. But it would appear that there is still something not entirely right in there. regards, Uwe
Uwe Hollerbach wrote:
Hello Barney & all, I've been following your messages with some interest, as I too have been trying to build a more-modern ghc on my G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and tried to build 6.8.3; I'm finally at the point where I have something to report, although I'm not sure if it's a success or a failure report... :-/
I applied your patch to package.conf.in (approximately; the relevant section wasn't quite identical), edited rts/Linker.c to add "#define LC_SEGMENT_64 LC_SEGMENT", and hacked up a wrapper script around ar to always ranlib the library being processed; you had mentioned patching cabal, but I decided the wrapper around ar was easier... a hack, but what the hell.
After that, "configure && make" ran to completion without errors (although it took a couple of days, since I had all the extralibs).
Success! ... or is it?
I installed the new compiler into /usr/local, then tested it by trying "ghc -v". Alas, no joy! It died with some dynamic-link error which I've approximately reproduced here:
lupus:~/ghc-6.8.3% ghc-6.8.3 -v dyld: relocation error (external relocation for symbol _pthread_mutex_unlock in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap
Failure! ... or is it?
I'd guess that the size of the binary has caused some kind of overflow of a short relocation field. Any experts in MacOS linking around? You might want to try the testsuite with stage1 and see whether the failure shows up anywhere else. Cheers, Simon
On 12/19/08, Simon Marlow
lupus:~/ghc-6.8.3% ghc-6.8.3 -v dyld: relocation error (external relocation for symbol _pthread_mutex_unlock in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap
Failure! ... or is it?
I'd guess that the size of the binary has caused some kind of overflow of a short relocation field. Any experts in MacOS linking around?
You might want to try the testsuite with stage1 and see whether the failure shows up anywhere else.
Cheers, Simon
Thanks, I will try that and see what I can find out. regards, Uwe
participants (7)
-
Barney Stratford -
Ian Lynagh -
Malcolm Wallace -
Simon Marlow -
Simon Peyton-Jones -
Thorkil Naur -
Uwe Hollerbach