While working on convenience libraries, I refactored how the inplace package database worked so that it was created at configure time (rather than when we do a build). This had the knock-on effect of causing us to pass the path to the inplace package database to GHC for all invocations, not just during builds.

It turns out this breaks ghc-cabal in GHC binary distributions, in the following way:

1. When GHC packages up libraries for the binary distribution, it packs up the configuration (LocalBuildInfo), interfaces and objects, but NOT the inplace database (who needs that!)
2. To install a package, we register it into the final database. register operates by running ghc --abi-hash, which following the aforementioned changes now points to the inplace package database. But the inplace package database doesn't exist, so GHC chokes.

I'll fix this, but I'm trying to decide between a few options:

1. Remove the -package-db flag when calling --abi-hash (they are not needed for GHC to operate correctly)
2. Compute ABI hash as part of build and stash it in a file somewhere, which register reads out later (I'd teach GHC's bindist to package up this file then)
3. Change GHC's bindist to copy the inplace DBs over and distribute them

There were also a number of things that would have made this easier to debug:

1. ghc-cabal really needs to grow a verbose flag (OK, not a Cabal bug)
2. The error message I got was:

ghc-cabal: '/home/hs01/ezyang/ghc-validate3/bindisttest/install
dir/lib/ghc-8.1.20160727/bin/ghc' exited with an error:
ghc: can't find a package database at dist-install/package.conf.inplace

This is not very useful. What would be more useful is if I had the full current working directory (that would have informed me WHICH library was failing), and if I had the FULL command line invocation to GHC (which would have notified me that this was due to an --abi-hash invocation.