August 2013 - ghc-devs

Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 29 Aug '13

29 Aug '13

Dear devs, I'm getting this build error when compiling GHC: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O -fasm -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o libraries/ghc-prim/GHC/Types.hs:1:1: Failed to load interface for 'GHC.Base' There are files missing in the 'base' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 I uploaded a full log of (perl boot && ./configure && make) here: http://www.cse.chalmers.se/~danr/log (3MB) At lines 2515- I can see this: "/home/dan/code/ghc/inplace/bin/ghc-pkg" update --force libraries/base/dist-install/inplace-pkg-config Reading package info from "libraries/base/dist-install/inplace-pkg-config" ... done. base-4.7.0.0: Warning: haddock-interfaces: /home/dan/code/ghc/libraries/base/dist-install/doc/html/base/base.haddock doesn't exist or isn't a file base-4.7.0.0: cannot find any of ["Control/Applicative.hi","Control/Applicative.p_hi","Control/Applicative.dyn_hi"] (ignoring) ... base-4.7.0.0: cannot find any of ["GHC/Base.hi","GHC/Base.p_hi","GHC/Base.dyn_hi"] (ignoring) Maybe this is related? I don't know if these ignores are expected. I've tried cloning the repo from http://git.haskell.org/ghc.git and the github mirror, I'm using the "quick" build flavour, but I've also tried adding DYNAMIC_BY_DEFAULT=NO DYNAMIC_GHC_PROGRAMS=NO before GhcLibWays' definition in mk/build.mk without success. Any ideas what could be wrong? Thanks, Dan

3 3

Re: make -jN loops on Windows
by Kyle Van Berendonck 29 Aug '13

29 Aug '13

Hi Simon, I think this is a MinGW bug. If we're talking about the same bug (lockup, no console output, task manager shows cpu but it doesn't produce files, etc) I get it when building other projects with -j too and I don't think its GHC's fault. Regards, Kyle Van Berendonck

3 6

Re: [Haskell-cafe] Building recent Cabal/cabal-install
by Johan Tibell 29 Aug '13

29 Aug '13

Hi, Cabal 1.18 is still in the release candidate stage so it has in fact not been released yet. We could either bump the dependency on base to <4.8 before the 1.8 release or we could make a Cabal-1.8.0.1 release together with the GHC release that bumps the dependency. -- Johan On Wed, Aug 28, 2013 at 9:08 PM, Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk>wrote: > Greetings café, > > There are some problems in Haddock to do with Template Haskell that I > believe are being caused by Cabal. These were apparently addressed in > 1.18 which came out recently. ‘Great!’, I thought. > > My problem is that I'm unsure how to use 1.18. I'm using GHC HEAD (well, > 3 days old now) which is meant to come with Cabal 1.18 (the library) and > in fact it seems to ship with it. Running ‘cabal --version’ however: > > > cabal-install version 1.17.0 > > using version 1.17.0 of the Cabal library > > I'm unsure how to get it to use 1.18. I tried to build cabal-install > from git but that just complains about dependencies not being possible > to resolve: it depends on HTTP which depends on base <4.7 but 4.7 comes > with GHC HEAD! > > I am baffled as to how I should go about using 1.18 and would love to > hear from some people who have this up and running. > -- > Mateusz K. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Disallow pushing of new trailing whitespace
by Jan Stolarek 29 Aug '13

29 Aug '13

Right now we have a git hook that prevents pushing a file containing tabs, unless that file had them already (in other words: no new files with tabs in our repos). I propose to add similar hook for trailing whitespaces. Herbert says he can implement that. What do others think? Would you find that useful or problematic? Janek

7 12

make install (at git ef01794) still fails
by Tuncer Ayaz 29 Aug '13

29 Aug '13

I think the last time 'make install' worked for me was sometime in February or March 2013. The build succeeds but 'make install' fails. Is this normal? git rev ef01794 linux i386 glibc 2.18 gcc 4.8.1 mk/build.mk: BuildFlavour = perf V = 0 $ perl boot $ ./configure --prefix=/tmp/ghc/7.7.20130827 $ make $ make install [...] Installing library in /tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/haskell2010-1.1.1.0 "/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg" --force --global-package-db "/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/package.conf.d" update rts/dist/package.conf.install /tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg: error while loading shared libraries: libHSbin-package-db-0.0.0.0-ghc7.7.20130827.so: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 Related: http://www.haskell.org/pipermail/ghc-devs/2013-March/000822.html http://www.haskell.org/pipermail/ghc-devs/2013-April/000995.html

1 1

FW: [GHC] #8186: Parallel comprehensions not allowed in Template Haskell quotes
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

With Gitolite, the Trac tickets now get messages like this: Comment (by Richard Eisenberg <eir@…>): In [changeset:382f601406b11b7d4fdc72d773c6060372f1fbb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="382f601406b11b7d4fdc72d773c6060372f1fbb3" Fix Trac #8186. Parallel list comprehensions are now handled in DsMeta. }}} But they used to get messages like this (like git log --stat) commit ef017944600cf4e153aad686a6a78bfb48dea67a Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Aug 27 15:48:02 2013 +0100 Comments only, relating to #8166 fix compiler/codeGen/StgCmm.hs | 7 ++----- compiler/codeGen/StgCmmExpr.hs | 7 ++++--- compiler/codeGen/StgCmmMonad.hs | 10 +++++++++- 3 files changed, 15 insertions(+), 9 deletions(-) I liked the old version: the author is more explicit the modified files are listed if the patch is small you see it all Might it be possible to revert? Simon

2 2

Backward compatibility
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

Dear Core Libraries Committee In addition to seeking your guidance about the comparison-primop question (a decision in the next few days would be most welcome), there are of course other breaking changes in GHC 7.8. High on the list is Typeable (see http://ghc.haskell.org/trac/ghc/ticket/8132) which has become polykinded, which is SO much better. Also, to guarantee the type-soundness of Typeable, we want to make it an error to use hand-rolled instances, rather than "deriving( Typeable )". The latter is very common anyhow, and the hand-rolled ones mostly use Typeable1 which is now heavily deprecated. There's a compatibility module Data.OldTypeable, but you'd have to import it to get the old behaviour. It's very difficult to really provide a "bumpless transfer", which is why Michael's idea of a compatibility package might be worth exploring. Anyway this is just a heads-up. Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0

Haskell.org down?
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

Haskell.org looks down from here. Also ghc.haskell.org. I've tried http://www.downforeveryoneorjustme.com, which agrees. Does anyone know what is going on? Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 2

Buidling profiled fails
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

I try "sh validate" with profiled libraries and get libraries/dph/ghc.mk:134: *** Cannot build profiled GHC with DPH; try deleting libraries/dph and trying again. Stop. So I obediently remove libraries/dph, and try again. But that fails too: Error: libraries/dph/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 84. Seems a bit Catch-22 ish. I'm not sure how to fix this. Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 4

RE: GHC TypeFamilies extension
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

We could do that, but personally I don't think it's worth it. I'm ccing ghc-devs in case anyone has a strong opinion. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 27 August 2013 21:45 | To: Simon Peyton-Jones; Dimitrios Vytiniotis | Cc: Stephanie Weirich | Subject: GHC TypeFamilies extension | | Hi Simon, Dimitrios, | | Among the various responses I've gotten to closed type families was a | complaint (made by a fellow Penn student, Daniel Wagner) about | extensions that change their meaning over time. Here is why: If a | package requires the use of a certain extension, it can declare the | extension in the cabal file, so that end users get a nice error message | if their GHC is out of date. However, if a package uses closed type | families, no such declaration is possible; an old GHC will just die with | a parse error. There are ways to insist on a certain version of GHC or a | version of the base library, but that doesn't seem great, either. | | On the other hand, I'm loathe to add yet another extension | ClosedTypeFamilies, forcing yet another pragma at the top of | programmers' files. | | Instead, we came up with this intermediate solution: | - Introduce two new extensions, OpenTypeFamilies and ClosedTypeFamilies | - TypeFamilies would imply both of these | - Appropriate checks would be made and error messages improved | | Now, users can still use TypeFamilies to get both flavors of type | families, but a package maintainer can specify ClosedTypeFamilies in a | cabal file to control which versions of GHC are usable. | | I'm still not 100% convinced this is the right idea, but there is enough | sense in it to ask. | | What do you think? If you all think this is a good enough idea, I'll | forward to glasgow-haskell-users for a wider discussion. | | Thanks, | Richard

1 0