can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
I've rm -rf'd my ~/.cabal to ensure old stuff doesn't get in the way, installed all the dependencies (on fedora 17, bootstrapping with ghc-7.0.4), unpacked the ghc-7.4.1 tarball, and run: ./configure --prefix=`pwd`/installed make make install and here's the log: https://gist.github.com/20dd47cfac4c8bbe498c (sorry I missed the top, `tee` didn't work right and my scrollback buffer wasn't big enough. I think I got the important stuff though). there seems to be a lot of */*.hi is missing (ignoring) messages, culminating in: Configuring hsc2hs-0.67... make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. make: *** [all] Error 2 Any hints? Cheers, - Tim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
On Wed, May 30, 2012 at 08:44:26PM +1000, Tim Cuthbertson wrote: Configuring hsc2hs-0.67... make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. make: *** [all] Error 2 Any hints? That file should be included in the source tarball. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
On Thu, May 31, 2012 at 2:41 AM, Ian Lynagh ig...@earth.li wrote: On Wed, May 30, 2012 at 08:44:26PM +1000, Tim Cuthbertson wrote: Configuring hsc2hs-0.67... make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. make: *** [all] Error 2 Any hints? That file should be included in the source tarball. Thanks Ian Ahh, whoops. I had done a `git init git add * git commit -m 'pristine'` so that I could see what changed after a full build, or easily start over if I did something wrong. But since I'd tried it a couple of times I'd also done a `git clean -fdx git reset --hard` (to get back to the pristine state). It turns out that some .gitignore files are included in the source tarball (all under libraries/*/.gitignore), so it actually cleaned up files that were supposed to be there. I'm not sure if it was intentional to include the .gitignore files in the tarball, but it seems like a surprising thing to do. Thanks, - Tim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
On 12/19/08, Simon Marlow marlo...@gmail.com wrote: 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 [EMAIL PROTECTED]@$(GHC_PATH)@g -e [EMAIL PROTECTED]@$(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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
On Mon, Nov 24, 2008 at 12:28:28PM +, 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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#options-codegen, -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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
in the days of ghc-6.2, you got -fvia-C by default The thing is, 6.2 is building 6.8 just fine. Stage 1 is quite happy. The problem arises during linking of Stage 2 - ie 6.8 can't build itself. Cheers, Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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#options-codegen, -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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 --- etc. -- IMO, many apple dev. tools are insidiously broken (Apple's cpp is my current nemesis). Could you try using a different linker? That might be a sufficient workaround. You could call gcc with the correct arguments to complete the linking phase, rather than ld (or vice-versa). The only other suggestion I've seen is to re-order the exported functions before compiling the library. I don't know if this would help in your case, but it has worked with other libraries. That's the best I can suggest, anyway. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
Re: Can't compile GHC 6.8.2
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Can't compile GHC 6.8.2
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: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Can't compile GHC 6.8.2
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Can't compile GHC 6.8.2
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC 6.8.2
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#options-codegen). 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bootstrapping using a C compiler (was: RE: Can't compile GHC)
Thanks for all the comments in this thread. I'm going to describe some of the technical issues with making a GHC distribution that you can bootstrap on any platform from a single set of sources below. But first, let me explain our thinking on why we don't consider this a priority: we aim to provide working binary distributions for 99.9% of the potential users of GHC. Once you have a working binary of GHC, building GHC again should be easy (if you run into problems, it's a *high* priority from our point of view to fix it). For the other 0.1%, we provide detailed instructions for porting GHC to your platform. It works, but it's a tricky process. Once you have *one* working GHC, you can build future versions probably for at least 4 years (we pull the ladder up after ourselves to avoid #ifdef-hell in the compiler). It may be that we don't have that 99.9% figure for 6.4, but when you consider versions back to 5.02 (the oldest version we can build 6.4 with, I believe), it's probably true. If your platform has a binary distribution, but you want to build GHC using just a C compiler for idealogical reasons, you're slightly misguided :-) -- Let me describe some of the technical issues with getting GHC to build out of the box, with no GHC binary installed, on any platform. Hopefully this will provide some useful pointers to anyone out there with a burning desire to improve the GHC OOB experience. How could we achieve a platform-independent bootstrap? The only way I can see to do this is to have a set of completely platform-independent .hc files to bootstrap from. Then the general plan would be - bootstrap unregisterised to get a stage1 compiler. stage1 might be reduced functionality: no GHCi, perhaps no native code gen, no template haskell. - use this to build fully registerised libraries stage2 To get our platform-independent .hc files, the contents of ghc/compiler ghc/lib ghc/utils libraries/base libraries/Cabal must all be compilable to platform-independent .hc code. That means - No platform #ifdefs in the Haskell code in these directories - No hsc2hs code in these directories We have to eradicate all platform #ifdefs, because they give rise to platform-varying .hc code. In practice, this will probably mean translating some code from Haskell to C. hsc2hs is a similar problem - that gives rise to platform-varying .hs code. Fortunately there is very little hsc2hs code left in here - it gives rise to other porting problems so we removed it. Our job is slightly easier: - As long as we still compile via-C, we can omit the native code generator in stage1, and build it in stage2 only. That's a big source of #ifdefs we don't have to worry about (arguably we should just compile in all the variants of the NCG anyway). However, our job is harder because - ghc/compiler/main/Constants.hs contains a bunch of baked-in constants such as the platform word-size. These would have to be made dynamic - or at least turned into unsafe reads of an external C variable. Given that a majority of the #ifdefs are Unix-vs-Windows, we could consider a partial solution, and settle for having two sets of .hc files, one for Unix and one for Windows. We could further split the Unix camp into 32-bit and 64-bit Unix, which makes the job even easier (the Constants.hs problem partly goes away). A few very rough figures: - total platform #ifdefs in the relevant sources: 395 - after omitting the native code gen: 148 - after omitting Windows: 28 - after omitting GHCi: 21 and there are 3 .hsc files in libraries/base, but they aren't necessary for bootstrapping. Hmm, it's starting to look plausible. Constants.hs is the biggest sticking point, and then hacking up the build system to do bootstrapping. Hope this has been of use to someone... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
robert dockins addresses this to - Daniel Carrera wrote: Hello, I've been trying to learn Haskell. ... At this point I decide that I'll teach people Python instead of Haskell. I don't particularly like Python, but hey, it works. Your choice, of course. I'll say more. You may buy to your kids a hamburger instead of ice cream. Your freedom, of course. But, please, don't say instead, it has a rather limited sense... Jerzy Karczmarczuk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
Andrew Cheadle wrote: :-p ok,ok, lots of people (but will they really continue to - we dropped it from our labs long ago). Having said that, how many people don't have access to a Windoze or Linux I don't have access to Win or Linux. But that's besides the point. I think it's reasonable to expect to compile ghc on a standard unix system. While this might be true, having a compiler compile itself is massively important Having the compiler able to compile itself, yes. Making that the only way to compile it, that's another thing. Daniel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
Well Robert Dockins gave you an excellent explanation. You're just unlucky at the moment with 6.4. 6.2.2 is excellent - for various reasons I've had to stick with it for completion of some of my research. Having the compiler able to compile itself, yes. Making that the only way to compile it, that's another thing. The .hc files exist for this reason. However for a popular platforms this isn't usually a problem, someone does the port quite quickly. You're just particularly unlucky with 6.4 since there has been substantial reworking of the internals. Andy * * Andrew Cheadleemail: [EMAIL PROTECTED] * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
robert dockins wrote: Perhaps. Nonetheless it is common practice for compilers to be written in the target language and to be compiled via bootstrapping. Ever take a look at the GCC sources? You guessed it: C. Please don't confuse the compiler being written in the target language with the compiler requiring itself. It should be possible to compile it with a compiler for a /different/ language. You can compile gcc with Sun's CC. You should be able to compile ghc with nh98. If this is the binary you found, it is possible you have an incorrect version of GCC. No, that's not it. I have 2.95 $ gcc --version 2.95.3 Best, Daniel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
On Mon, 2005-05-09 at 09:54 -0400, Daniel Carrera wrote: Hello, I've been trying to learn Haskell. Some software isn't user friendly. But I think that a compiler requiring itself to compile is actively user hostile. I've spent over a week trying to get GHC to work on my Solaris workstation and I've concluded that it just isn't going to happen. We use Solaris on our student workstations at my university. We've got version of ghc going back as far as ghc 0.29! We currently use 6.2.2. I tried to compile GHC but it said taht it needed GHC to compile. I read the README trying to find out what people without ghc are supposed to do to install ghc. But no instructions are found. I check the website, hoping to find a binary. I find an old binary, but it just won't work. Something about libgcc_s.so.1. This route is going to be your best bet. Find any binary version of ghc that works on your Solaris and then from there you've broken the GHC-GHC dep cycle. So once you've got any binary version of GHC installed (going back as far as 4.08.x) then you can build the version you want from source. As other peole have said, you want version 6.2.2 since this is a very stable/bug-free version and it works just fine on Solaris. Another quick way to get something to teach Haskell is to just use Hugs. We've used Hugs for years for teaching students. It's only now that we're finally switching to ghc/ghci. If you do still find that you're completely stuck in getting a binary version working I'm sure you/we could persuade the IT people in my department to send you a binary snapshot (so long as it is for some educational purpose/institution). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
Duncan Coutts wrote: This route is going to be your best bet. Find any binary version of ghc that works on your Solaris and then from there you've broken the GHC-GHC dep cycle. Okay. Is there a version that's more likely to work than others? Or should I try them sequentially from most recent, then go backwards? Best, Daniel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
2005-05-09T16:09:16 Daniel Carrera: I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible. This is a first barrier only for users on platforms that don't currently have ghc maintainers. Given how tricksy it is getting a working ghc build, even on a supported platform, doing so is relegated to the few and devoted; new users are only welcome on the platforms for which pre-built ghc binaries are available. I agree with you, Daniel, that this is a terribly unfortunate state of affairs, but as has already been said, the folks who are doing the actual work (I ain't one of 'em) have decided that making ghc easier to bootstrap onto a supported platform is not a priority for them, they're content that virtually all ghc users should have to download prebuilt binaries, or source packages on platforms where devoted souls have built working automated builds. -Bennett pgpNjOIPwMXGg.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible. Without commenting on any of the other points raised in this thread, I must agree with this. I am new to Haskell. I consider becoming proficient in Haskell programming a worthy goal in itself. However, making Haskell useful beyond an academic context is difficult because of the limitations you face with the tools, both in terms of installing and using those tools and the fact that some tools simply aren't available. I say this because I have been evaluating Haskell for use in my senior project. I need a stable and usable graphics toolkit for the project. While graphics toolkits for Haskell do exist, they are oftentimes either translations of other bindings that don't quite work, incompatible between platforms, limited in their utility, or in some cases, abandonware that represented the heroic effort of a lone programmer that disappeared when that programmer lost interest or moved on to other projects. I am not saying this to disparage the hard work of those who develop and maintain GHC and other Haskell compilers/runtime environments. That work is very much appreciated. And I can understand that people will become impatient when somebody expresses a sentiment in the form of well, your product sucks so I'm going to use somebody else's. GHC is a good product. Haskell is not GHC or any particular implementation, although in the end, the utility of the platform can determine the success of the language. Python is easier to use because it has a larger standard API and considerable effort has gone into making it portable across many platforms. This may be a simple issue of resources, I don't know. It is my understanding that those who participated in creating and standardizing Haskell did so with the goal of reducing the proliferation of functional programming languages and creating a functional programming language that would combine best practice features and promote the use of this programming model in preference to the older imperative style. But at the end of the day, you have to be able to use it to do stuff. A devotion to a good concept only goes so far if the second-best concept can get stuff done with a fraction of the effort. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
On Mon, 2005-05-09 at 21:26 -0400, Mark Brooks wrote: I say this because I have been evaluating Haskell for use in my senior project. I need a stable and usable graphics toolkit for the project. While graphics toolkits for Haskell do exist, they are oftentimes either translations of other bindings that don't quite work, incompatible between platforms, limited in their utility, or in some cases, abandonware that represented the heroic effort of a lone programmer that disappeared when that programmer lost interest or moved on to other projects. May I direct your attention to two working, extensive, portable (with native look), actively developed Haskell GUI library bindings: Gtk2Hs: http://haskell.org/gtk2hs/ wxHaskell: http://wxhaskell.sourceforge.net/ Incidentally, both of these projects are quite mature and are nearing 1.0 releases. If you find any issue with either binding, I'm sure bug reports would be gratefully accepted. Duncan (disclaimer: Gtk2Hs developer) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't compile GHC
On May 9, 2005, at 4:55 PM, Bennett Todd wrote: 2005-05-09T16:09:16 Daniel Carrera: I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible. This is a first barrier only for users on platforms that don't currently have ghc maintainers. Given how tricksy it is getting a working ghc build, even on a supported platform, doing so is relegated to the few and devoted; new users are only welcome on the platforms for which pre-built ghc binaries are available. I'll echo this. The Darwinports GHC build is the first time I've ever gotten GHC to build out of the box. Previous attempts have required multiple hours of hacking, even with a same-version binary installed on the same platform. Part of that was being burdened with variously non-standard machine configurations. But mostly it's because the fptools build structure was historically pretty fragile, and stuff broke badly if it didn't get built in just the right order with just the right versions of things. On many occasions I just gave up and kept the sources around for reference only (eg to look things up in the library code when the docs were fuzzy...). My perception is that this is improving with time. But it's still a big time investment. Certainly I don't expect to ever have the time to coax GHC to build from source on Solaris nowadays. -Jan-Willem Maessen I agree with you, Daniel, that this is a terribly unfortunate state of affairs, but as has already been said, the folks who are doing the actual work (I ain't one of 'em) have decided that making ghc easier to bootstrap onto a supported platform is not a priority for them, they're content that virtually all ghc users should have to download prebuilt binaries, or source packages on platforms where devoted souls have built working automated builds. -Bennett ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: can't compile ghc from cvs
I think it's a legitimate problem with the new driver. I hit it myself on Friday. I think that the _Capitalised entity naming scheme is being misinterpreted by pre-4.07 ghc's. ... and I see that Sven has already fixed it. Cool. J
Re: can't compile ghc from cvs
Jens-Ulrik Petersen wrote: For some time I haven't been able to compile ghc from cvs. [...] What's going wrong? [...] Config.hs:2: Data constructor not in scope: `_ProjectName' [...] Until recently (including 4.06) GHC confused variables having names starting with an underscore followed by an uppercase letter with data constructors. This has been fixed for 4.07, but as people are supposed to be able to build 4.07 with pre-4.07 compilers, I'll change those identifiers in the driver sources with something more defensive. The commit will follow soon... Cheers, Sven
Re: can't compile ghc from cvs
Sven Panne wrote: [...] This has been fixed for 4.07, but as people are supposed to be able to build 4.07 with pre-4.07 compilers, I'll change those identifiers in the driver sources with something more defensive. I've just realised that this is not the true story. You *can* build 4.07 with =4.06, but not the CVS version with anything 4.07. But I'll fix it anyway. Cheers, Sven
