Hello, I'm trying to compile HEAD on amd64-solaris2 platform, but the build fails with: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/haddock-library/vendor/attoparsec-0.10.4.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.20.0.1 -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140715 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o utils/haddock/src/Haddock/GhcUtils.hs:105:21: Not in scope: data constructor ‘TyFamInstEqn’ Perhaps you meant ‘TyFamInstD’ (imported from GHC) utils/haddock/src/Haddock/GhcUtils.hs:105:36: ‘tfie_rhs’ is not a (visible) constructor field name gmake[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1 gmake: *** [all] Error 2 is this just issue on my system or general issue which waits for someone to resolve it? Since I built HEAD successfully just two days ago, this patch may looks suspiciously: commit 9b8ba62991ae22420a0c4486127a3b22ee7f22bd Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Tue Jul 15 07:43:55 2014 +0100 Entirely re-jig the handling of default type-family instances (fixes Trac #9063) In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well. but I'm not expert so no offense! And if this is a mistake on my side, then I'm really sorry for false alarm. Thanks! Karel