When building GHC: Failed to load interface for `GHC.Fingerprint'

[igloo]

when doing a build with THREADS=1, we are getting things like:

inplace/bin/ghc-stage1 [...] -c libraries/time/./Data/Time/Calendar/Days.hs [...]
/home/ian/ghc/git/ghc/libraries/base/dist-install/build/Data/Typeable/Internal.dyn_hi
Declaration for mkTyConApp
Unfolding of Data.Typeable.Internal.mkTyConApp:
  Failed to load interface for `GHC.Fingerprint'
  Perhaps you haven't installed the "dyn" libraries for package `base'?
  Use -v to see a list of the files searched for.
/home/ian/ghc/git/ghc/libraries/base/dist-install/build/Data/Typeable.dyn_hi
Declaration for mkTyCon
Unfolding of Data.Typeable.mkTyCon:
  Can't find interface-file declaration for variable GHC.Fingerprint.fingerprintString
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error

(we only have Fingerprint.dyn_hi-boot). GHC still exits successfully, however.

[igloo]

OK, it looks like this goes wrong because of the way we interleave the building of packages when building GHC. GHC assumes that if we're building one package, then packages that it depends on have already been built and are complete. Therefore, even if a module in the other package has a .hs-boot file, the real .hs file will also have been compiled and there will be a full .hi file.

That seems like a reasonable assumption to make, and it doesn't look like anything actually fails as a result of this, so I don't think we need to take any action.

[simonpj]

Replying to igloo:

OK, it looks like this goes wrong because of the way we interleave the building of packages when building GHC. GHC assumes that if we're building one package, then packages that it depends on have already been built and are complete. Therefore, even if a module in the other package has a .hs-boot file, the real .hs file will also have been compiled and there will be a full .hi file. That seems like a reasonable assumption to make, and it doesn't look like anything actually fails as a result of this, so I don't think we need to take any action.

Ian I'm far from certain that your diagnosis here is correct, and indeed I don't really understand it. Yes, the assumption you describe seems a reasonable one. Does it not hold? Does not-holding have consequences of missing unfoldings? GHC is, I believe, happy to accept either a .hi file or a .hi-boot file.

[igloo]

No, our build system doesn't build the modules in package order. For example, it might build directory:System.Directory before base:Control.Arrow (assuming System.Directory doesn't transitively import Control.Arrow).

This removes a load of dependencies, so makes the build more parallelisable.

If I remember correctly, the problem in this ticket was that we have something like:

Package a: X imports Y and Y imports X-boot.
Package b: Z imports Y (from package a)

and an inlining in Y refers to X.x.

We compile X-boot, then Y, then Z. When compiling Z, we expect X.hi to exist, and look in it to see if there's an inlining for x.

[simonpj]

Hmm. I still don't get it. Y.hi will not expect X.hi to exist. So Z, which imports Y.hi, won't expect X.hi to exist either, will it? It'll just look in X.hi-boot.

[igloo]

I've added a test T7373 which shows what is going on. Currently it fails with:

+/home/ian/ghc/git/ghc/testsuite/tests/driver/T7373/pkg/dist/build/C.hi
+Declaration for mkTyConApp
+Unfolding of C.mkTyConApp:
+  Failed to load interface for ‛B’
+  There are files missing in the ‛pkg-0’ package,
+  try running 'ghc-pkg check'.
+  Use -v to see a list of the files searched for.