
On 14/10/2009 04:43, Antoine Latter wrote:
On Sun, Oct 11, 2009 at 3:41 PM, Ian Lynagh
wrote: Hi all,
We are pleased to (finally!) announce the first release candidate for GHC 6.12.1:
http://darcs.haskell.org/~ghc/dist/6.12.1rc1/
As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs.
Please test as much as possible; bugs are much cheaper if we find them before the release!
Here is my tale of woe. I'm running this on Mac OS X 10.6.
I tried to install the syb-with-class package off of hackage, which initially failed because of the changes to the template-haskell package installed with 6.12.1rc1.
So I think to myself "Oh! I'll just put an upper bound on the version of template-haskell used in the .cabal file for syb, and install the old version off of hackage".
The current version of template-haskell installs fine on 6.12.1rc1 with a couple minor tweaks (to compensate for StringConstr not being present in Data.Data anymore).
But then when I try to build syb-with-class against the old template-haskell lib I get the following error:
$ ./Setup build Preprocessing library syb-with-class-0.5.1... Building syb-with-class-0.5.1... [3 of 4] Compiling Data.Generics.SYB.WithClass.Derive ( Data/Generics/SYB/WithClass/Derive.hs, dist/build/Data/Generics/SYB/WithClass/Derive.o )
Data/Generics/SYB/WithClass/Derive.hs:23:0: Bad interface file: /Users/alatter/.cabal/lib/template-haskell-2.3.0.1/ghc-6.12.0.20091010/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.3.0.1:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH <<<<<
Has anyone seen this before? Are there any tools I can use to peer into .hi files to get more information about what could be wrong?
template-haskell is a one of the packages that we call "wired-in", because GHC needs to generate references to some of the things that it defines. To make GHC independent of the version of the template-haskell package, we internally strip off the version number when referring to template-haskell. Now, this doesn't completely explain the error you're seeing. When it starts up, GHC has to decide which template-haskell package is the "wired-in" one, and my guess is that it picked the other one (because it is newer). You could find out by running GHC with the -v flag. I think GHC is assuming that when you have multiple versions of a wired-in package that the older ones are wrappers around the newer ones (like base-3 and base-4), but that assumption doesn't hold in your case. Installing a new version of a wired-in package is going to be problematic, but we ought to be able to at least improve the diagnostics. Cheers, Simon