
We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

Ian Lynagh wrote:
We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1.
You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources
It's also available in Gentoo Linux, hard masked. If you're not already familiar with the Gentoo Haskell overlay, use layman[1] to get the haskell overlay and unmask[2] the packages dev-lang/ghc and dev-haskell/cabal. Then, simply: $ emerge ghc Cheers, Lennart Kolmodin [1] http://www.gentoo.org/proj/en/overlays/userguide.xml [2] http://gentoo-wiki.com/Masked#Hard_Masked

I am using the gentoo package for 6.10.1 and when i start ghci it tries to allocate over 1gb of memory, which hits my ulimit. Is anyone else getting absurd memory usage when trying to start ghci? $ ghci GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. ghc: out of memory (requested 1048576 bytes

Anatoly Yakovenko wrote:
I am using the gentoo package for 6.10.1 and when i start ghci it tries to allocate over 1gb of memory, which hits my ulimit.
Is anyone else getting absurd memory usage when trying to start ghci? $ ghci GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. ghc: out of memory (requested 1048576 bytes
Likely the same bug we've seen before with libedit, or related; GHC bug reported at http://hackage.haskell.org/trac/ghc/ticket/2716 (closed as invalid as the problem isn't with GHC) Gentoo bug report at http://bugs.gentoo.org/237882 to fix gentoo's libedit. You can try to apply the patch in the gentoo bug locally and see if that resolves the issue. Cheers, Lennart K

Ian Lynagh
We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1.
The build problems I reported about the 20080921 beta are still present: I ran into some problems due to having gmp installed in an unusual place. I passed --with-gmp-{includes,libraries} to ./configure, set $CPPFLAGS and $LDFLAGS for ./configure, and set the corresponding -optl, etc., flags in SRC_HC_OPTS and GHC_CC_OPTS in mk/build.mk. With all that, the first problem I hit was with utils/pwd/pwd. ./configure builds it by calling ghc without any special flags, so the binary can't find libgmp.so at runtime. pwd is compiled and linked without problems; it just can't run. So it seems the bootstrap compiler knows where its gmp is, and is providing the necessary -L flags, but not -Xlinker -R. I got past this by editing ./configure to add the necessary flags to the build command, but I wonder if turning pwd into a C program would be less troublesome. The next problem was with cabal-bin. The command to build it didn't use SRC_HC_OPTS, so that binary also couldn't find libgmp.so when it ran. I used this patch: --- libraries/Makefile~ 2008-09-21 13:06:31.000000000 -0400 +++ libraries/Makefile 2008-09-23 01:58:29.000000000 -0400 @@ -131,7 +131,7 @@ cabal-bin: cabal-bin.hs -mkdir bootstrapping - $(GHC) $(BOOTSTRAPPING_FLAGS) --make cabal-bin -o cabal-bin + $(GHC) $(BOOTSTRAPPING_FLAGS) $(SRC_HC_OPTS) --make cabal-bin -o cabal-bin bootstrapping.conf: cabal-bin echo "[]" > $@.tmp @@ -154,9 +154,9 @@ mkdir ifBuildable $(CP) ifBuildable.hs ifBuildable/ ifeq "$(stage)" "2" - cd ifBuildable && ../$(HC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && ../$(HC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable else - cd ifBuildable && $(GHC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && $(GHC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable endif .PHONY: all build configure That gets me to this point: Preprocessing library hpc-0.5.0.2... dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make >dist-bootstrapping/build/Trace/Hpc/Reflect.hs make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.10.0.20080921+spf+0/compile/src/ghc-6.10.0.20080921/libraries' make: *** [stage1] Error 2 I'm not sure how to fix this. I assume there's some way to pass SRC_HC_OPTS to cabal-bin, but I don't know how. paul

Hi Paul, On Wed, Oct 08, 2008 at 06:04:31PM -0400, Paul Jarc wrote:
With all that, the first problem I hit was with utils/pwd/pwd. ./configure builds it by calling ghc without any special flags, so the binary can't find libgmp.so at runtime.
I think you need to tell the dynamic linker where to find it, e.g. by setting DYLD_LIBRARY_PATH. See the dyld manpage for more information. Thanks Ian

Ian Lynagh
On Wed, Oct 08, 2008 at 06:04:31PM -0400, Paul Jarc wrote:
With all that, the first problem I hit was with utils/pwd/pwd. ./configure builds it by calling ghc without any special flags, so the binary can't find libgmp.so at runtime.
I think you need to tell the dynamic linker where to find it, e.g. by setting DYLD_LIBRARY_PATH. See the dyld manpage for more information.
I'm on GNU/Linux, so it would be LD_LIBRARY_PATH for me. Yes, that would be another useable workaround for pwd. What about the other problems I mentioned? Regardless of my problems, it seems like a build bug that SRC_HC_OPTS isn't used for some compilations. Is SRC_HC_OPTS meant to be used for all Haskell compilations in the build process, or am I misunderstanding its purpose?
The next problem was with cabal-bin. The command to build it didn't use SRC_HC_OPTS, so that binary also couldn't find libgmp.so when it ran. I used this patch:
--- libraries/Makefile~ 2008-09-21 13:06:31.000000000 -0400 +++ libraries/Makefile 2008-09-23 01:58:29.000000000 -0400 @@ -131,7 +131,7 @@
cabal-bin: cabal-bin.hs -mkdir bootstrapping - $(GHC) $(BOOTSTRAPPING_FLAGS) --make cabal-bin -o cabal-bin + $(GHC) $(BOOTSTRAPPING_FLAGS) $(SRC_HC_OPTS) --make cabal-bin -o cabal-bin
bootstrapping.conf: cabal-bin echo "[]" > $@.tmp @@ -154,9 +154,9 @@ mkdir ifBuildable $(CP) ifBuildable.hs ifBuildable/ ifeq "$(stage)" "2" - cd ifBuildable && ../$(HC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && ../$(HC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable else - cd ifBuildable && $(GHC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && $(GHC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable endif
.PHONY: all build configure
That gets me to this point:
Preprocessing library hpc-0.5.0.2... dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make >dist-bootstrapping/build/Trace/Hpc/Reflect.hs make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/fs/pkgs/mount/package/host/code.dogmap.org/foreign/ghc-6.10.0.20080921+spf+0/compile/src/ghc-6.10.0.20080921/libraries' make: *** [stage1] Error 2
I'm not sure how to fix this. I assume there's some way to pass SRC_HC_OPTS to cabal-bin, but I don't know how.
paul

Hi Paul, On Mon, Oct 27, 2008 at 03:29:20PM -0400, Paul Jarc wrote:
Ian Lynagh
wrote: On Wed, Oct 08, 2008 at 06:04:31PM -0400, Paul Jarc wrote:
With all that, the first problem I hit was with utils/pwd/pwd. ./configure builds it by calling ghc without any special flags, so the binary can't find libgmp.so at runtime.
I think you need to tell the dynamic linker where to find it, e.g. by setting DYLD_LIBRARY_PATH. See the dyld manpage for more information.
I'm on GNU/Linux, so it would be LD_LIBRARY_PATH for me.
Oh, sorry, for some reason I had it in my head that you were on OS X.
Yes, that would be another useable workaround for pwd. What about the other problems I mentioned?
I thought all your problems boiled down to binaries not being able to find libgmp.so at runtime? So I think this should fix them all. The build system assumes that the bootstrapping compiler knows how to build Haskell programs that can just be run.
Regardless of my problems, it seems like a build bug that SRC_HC_OPTS isn't used for some compilations. Is SRC_HC_OPTS meant to be used for all Haskell compilations in the build process, or am I misunderstanding its purpose?
You are probably right that it should technically be passed. Thanks Ian

Ian Lynagh
I thought all your problems boiled down to binaries not being able to find libgmp.so at runtime? So I think this should fix them all.
Yes, but then I wouldn't be able to find and fix the commands that are missing SRC_HC_OPTS. :) So I'm holding off on that for now. Below is a patch for the ones I've found so far. With those changes, and without setting LD_LIBRARY_PATH, the build stops here: Preprocessing library hpc-0.5.0.2... dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make >dist-bootstrapping/build/Trace/Hpc/Reflect.hs My BUILD_FLAGS includes --ghc-option=-optl... and --ld-option=... flags which would take care of it, if they were being used, so apparently they're not. libraries/hpc/Trace/Hpc/Reflect.hsc produces libraries/hpc/dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.c, which is compiled and linked to make libraries/hpc/dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make. Is there anything I can add to the cabal-bin command line to inject linker flags into that link command? --- libraries/Makefile 2008-10-07 15:30:24.000000000 -0400 +++ libraries/Makefile 2008-10-31 11:58:25.000000000 -0400 @@ -131,21 +131,21 @@ cabal-bin: cabal-bin.hs -mkdir bootstrapping - $(GHC) $(BOOTSTRAPPING_FLAGS) --make cabal-bin -o cabal-bin + $(GHC) $(BOOTSTRAPPING_FLAGS) $(SRC_HC_OPTS) --make cabal-bin -o cabal-bin bootstrapping.conf: cabal-bin echo "[]" > $@.tmp -cd filepath && $(CABAL) clean --distpref=dist-bootstrapping cd filepath && $(CABAL) configure --distpref=dist-bootstrapping --with-compiler=$(GHC) --with-hc-pkg=$(GHC_PKG) --package-db=$(HERE_ABS)/$@.tmp - cd filepath && $(CABAL) build --distpref=dist-bootstrapping + cd filepath && $(CABAL) build --distpref=dist-bootstrapping $(BUILD_FLAGS) cd filepath && $(CABAL) install --distpref=dist-bootstrapping --inplace -cd Cabal && $(CABAL) clean --distpref=dist-bootstrapping cd Cabal && $(CABAL) configure --distpref=dist-bootstrapping --with-compiler=$(GHC) --with-hc-pkg=$(GHC_PKG) --package-db=$(HERE_ABS)/$@.tmp - cd Cabal && $(CABAL) build --distpref=dist-bootstrapping + cd Cabal && $(CABAL) build --distpref=dist-bootstrapping $(BUILD_FLAGS) cd Cabal && $(CABAL) install --distpref=dist-bootstrapping --inplace -cd hpc && $(CABAL) clean --distpref=dist-bootstrapping cd hpc && $(CABAL) configure --distpref=dist-bootstrapping --with-compiler=$(GHC) --with-hc-pkg=$(GHC_PKG) --package-db=$(HERE_ABS)/$@.tmp - cd hpc && $(CABAL) build --distpref=dist-bootstrapping + cd hpc && $(CABAL) build --distpref=dist-bootstrapping $(BUILD_FLAGS) cd hpc && $(CABAL) install --distpref=dist-bootstrapping --inplace mv $@.tmp $@ @@ -154,9 +154,9 @@ mkdir ifBuildable $(CP) ifBuildable.hs ifBuildable/ ifeq "$(stage)" "2" - cd ifBuildable && ../$(HC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && ../$(HC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable else - cd ifBuildable && $(GHC) -Wall --make ifBuildable -o ifBuildable + cd ifBuildable && $(GHC) -Wall $(SRC_HC_OPTS) --make ifBuildable -o ifBuildable endif .PHONY: all build configure

Paul Jarc wrote:
Ian Lynagh
wrote: I thought all your problems boiled down to binaries not being able to find libgmp.so at runtime? So I think this should fix them all.
Yes, but then I wouldn't be able to find and fix the commands that are missing SRC_HC_OPTS. :) So I'm holding off on that for now. Below is a patch for the ones I've found so far. With those changes, and without setting LD_LIBRARY_PATH, the build stops here:
Technically speaking, we should pass $(HC_OPTS) to any Haskell compilations. That includes $(SRC_HC_OPTS), but also a bunch of other things. Cheers, Simon

Ian Lynagh wrote:
Please test as much as possible; bugs are much cheaper if we find them before the release!
How about a test-suite? Cheers Christian P.S. "make binary-dist" creates a big unnecessary ".tar" file together with the final ".tar.bz2" file. Also a (disturbing) link "ghc-6.10.0.20081007 -> ." is created. ("make install" no longer reports which path to add)

On Thu, Oct 09, 2008 at 03:37:32PM +0200, Christian Maeder wrote:
Ian Lynagh wrote:
Please test as much as possible; bugs are much cheaper if we find them before the release!
How about a test-suite?
Good point: I've addde one to http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html
P.S. "make binary-dist" creates a big unnecessary ".tar" file together with the final ".tar.bz2" file. Also a (disturbing) link "ghc-6.10.0.20081007 -> ." is created.
The link is deliberate (we tar things up from the build tree, rather than making a ghc-6.10.0.20081007 directory and copying them there).
("make install" no longer reports which path to add)
Ooops, the logic for whether to print the message was the wrong way round. Now fixed. Thanks Ian

Ian Lynagh wrote:
http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html
My testsuite results can be found under: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... 371 unexpected failures resp. 195 unexpected failures Christian

On Wed, Oct 8, 2008 at 1:09 PM, Ian Lynagh
We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1.
You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources
There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform.
Please test as much as possible; bugs are much cheaper if we find them before the release!
We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered.
Thanks Ian, on behalf of the GHC team
Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are not thrown in ghci, probably because it installs its own signal handlers: Prelude Control.Exception Control.Concurrent> handle (\UserInterrupt -> putStrLn "Caught!") (threadDelay 2000000) ^CInterrupted. For consistency between the compiled and interpreted environments, it would be nice if the above could catch the ctrl-c. But maybe there's a reason not to do this? If this change sounds OK, I can take a look at this and try to put together a patch over the weekend. Thanks, -Judah

Judah Jacobson wrote:
Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are not thrown in ghci, probably because it installs its own signal handlers:
Prelude Control.Exception Control.Concurrent> handle (\UserInterrupt -> putStrLn "Caught!") (threadDelay 2000000) ^CInterrupted.
For consistency between the compiled and interpreted environments, it would be nice if the above could catch the ctrl-c. But maybe there's a reason not to do this? If this change sounds OK, I can take a look at this and try to put together a patch over the weekend.
Hmm, tricky one. I agree with the argument for consistency, but on the other hand you might also want a way to interrupt a computation regardless, and that almost works - as long as the program isn't discarding exceptions it knows nothing about. Cheers, Simon

Simon Marlow wrote:
Judah Jacobson wrote:
Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are not thrown in ghci, probably because it installs its own signal handlers:
Prelude Control.Exception Control.Concurrent> handle (\UserInterrupt -> putStrLn "Caught!") (threadDelay 2000000) ^CInterrupted.
For consistency between the compiled and interpreted environments, it would be nice if the above could catch the ctrl-c. But maybe there's a reason not to do this? If this change sounds OK, I can take a look at this and try to put together a patch over the weekend.
Hmm, tricky one. I agree with the argument for consistency, but on the other hand you might also want a way to interrupt a computation regardless, and that almost works - as long as the program isn't discarding exceptions it knows nothing about.
In my mind this is, at least thematically, related to http://hackage.haskell.org/trac/ghc/ticket/1399 that is, it relates to the various ways that running in ghci is different from running independently. To get a really good answer I think we need a couple of RTS enhancements, the ability to have a kind 'supervisor' mode etc... Jules
participants (8)
-
Anatoly Yakovenko
-
Christian Maeder
-
Ian Lynagh
-
Judah Jacobson
-
Jules Bean
-
Lennart Kolmodin
-
prj@po.cwru.edu
-
Simon Marlow