GitLab

Consider the following build log. In particular note that we start by cleaning any local build files (rm dist).

Additionally, the user reports that transformers is not installed and ghc-pkg check reports no problems.

00:14:25 | morn@twi:~/dev/darcs/fastconvert -> rm -rf dist 
00:14:27 | morn@twi:~/dev/darcs/fastconvert -> cabal configure -v
[...]
Dependency attoparsec ==0.8.1.1: using attoparsec-0.8.1.1
Dependency base ==4.2.0.0: using base-4.2.0.0
Dependency bytestring ==0.9.1.5: using bytestring-0.9.1.5
Dependency cmdlib ==0.3: using cmdlib-0.3
Dependency containers ==0.3.0.0: using containers-0.3.0.0
Dependency darcs ==2.5: using darcs-2.5
Dependency datetime ==0.2: using datetime-0.2
Dependency directory ==1.0.1.0: using directory-1.0.1.0
Dependency filepath ==1.1.0.3: using filepath-1.1.0.3
Dependency hashed-storage ==0.5.4: using hashed-storage-0.5.4
Dependency mtl ==1.1.1.0: using mtl-1.1.1.0
Dependency old-time ==1.0.0.3: using old-time-1.0.0.3
Dependency utf8-string ==0.3.6: using utf8-string-0.3.6
Using Cabal-1.8.0.2 compiled by ghc-6.12
Using compiler: ghc-6.12.1
[...]
00:14:31 | morn@twi:~/dev/darcs/fastconvert -> cabal build -v          
[...]
/usr/bin/ghc --make -o dist/build/darcs-fastconvert/darcs-fastconvert -hide-all-packages -fbuilding-cabal-package -package-conf dist/package.conf.inplace -i -idist/build/darcs-fastconvert/darcs-fastconvert-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/darcs-fastconvert/darcs-fastconvert-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -hidir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -stubdir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -package-id attoparsec-0.8.1.1-280af3ab9743111575ea0031e8a83455 -package-id base-4.2.0.0-73995e854f236dc2acd577d7c791221d -package-id bytestring-0.9.1.5-2d4a9d624c3be86b70c04730e5f12aca -package-id cmdlib-0.3-3ef785632945f8811c8ebbd1d2e9345b -package-id containers-0.3.0.0-409fe3b8f0dda25b98e03716d26be411 -package-id darcs-2.5-47653bbe1982b022915b3fa65161767f -package-id datetime-0.2-6f38d66fddaaa0ccccffea38d6fe8d60 -package-id directory-1.0.1.0-10fc46e61b67ff4a83f3e553454d003c -package-id filepath-1.1.0.3-07812de93a673f50011d47451bcaac87 -package-id hashed-storage-0.5.4-8a6b02d90d8e1d05f233c1e31eb4a367 -package-id mtl-1.1.1.0-7772b7b72936d947193a773ada65461a -package-id old-time-1.0.0.3-b53830b41b1085071f61ca7772f44e0c -package-id utf8-string-0.3.6-a7e240d06fa0c09cfff1a5445b521d24 -O -Wall -fno-warn-unused-do-bind ./main.hs
[1 of 5] Compiling Utils            ( Utils.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Utils.o )
[...]
[3 of 5] Compiling Import           ( Import.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Import.o )
Failed to load interface for `Control.Monad.Trans.Error':
  no package matching `transformers-0.2.2.0' was found

The message

Failed to load interface for `Control.Monad.Trans.Error':
  no package matching `transformers-0.2.2.0' was found

appears to be due to a .hi file from one of the dependencies of the current compilation. This hi file references a module from the transformers package.

1. it is hard for a user to know what is causing this module to be looked up (ie that it is a .hi file)
2. it is almost impossible to work out which existing registered package contains a .hi file that refers to the non-existent transformers package.

If the error message specified that it was a .hi file that caused the lookup and gave e.g. the file name (or package+ver+module) of the .hi file that caused the lookup of transformers then this would make it much easier for the user to work out what is going on and which registered package is at fault: e.g.

Failed to load interface for `Control.Monad.Trans.Error':
  the package `transformers-0.2.2.0' was found
  referenced by `Data.Foo` from `foo-1.0`.

Clearly there is a deeper problem here, that a registered package is out-of-sync with its registration information: the .hi refers to a package that is not mentioned in the package registration.

One way this could happen is due to inplace registrations, since it is easy in that case to rebuild the inplace .hi files without also re-registering. It may be sensible to rethink how Cabal does inplace registrations to prevent it getting out of sync.

We may also wish to have a ghc-pkg register/update/check mode that reads the .hi files and verifies them against the package registration info.

Trac metadata

Trac field	Value
Version	6.12.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture