ANNOUNCE: GHC 6.12.1 Release Candidate 1
marlowsd at gmail.com
Wed Oct 14 05:34:27 EDT 2009
On 14/10/2009 04:43, Antoine Latter wrote:
> On Sun, Oct 11, 2009 at 3:41 PM, Ian Lynagh<igloo at earth.li> wrote:
>> Hi all,
>> We are pleased to (finally!) announce the first release candidate
>> for GHC 6.12.1:
>> As well as the source tarball:
>> 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"
>> 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 (
> dist/build/Data/Generics/SYB/WithClass/Derive.o )
> Bad interface file:
> Something is amiss; requested module
> template-haskell-220.127.116.11: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
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.
More information about the Glasgow-haskell-users