Package abi hash and interface file versions
marlowsd at gmail.com
Wed Jul 13 10:11:32 CEST 2011
On 11/07/2011 21:56, Joachim Breitner wrote:
> in Debian, we use the ghc-pkg ABI hashes to find out what packages we
> need to rebuild when. So far, the system has worked great. But now
> something unfortunate happened: Yesterday, I upgraded ghc from 7.0.3 to
> 7.0.4. The ABI hash of base and other libraries changed only on amd64
> and kfreebsd-amd64, while they stays unmodified on the other
> architectures. That by itself is interesting, but nothing to worry
> about, as I assumed that the hashes ensure that packages are rebuild
> where required.
> But now I see this build log:
> with the relevant line:
> Bad interface file: /usr/lib/haskell-packages/ghc/lib/mtl-18.104.22.168/ghc-7.0.3/Control/Monad/Trans.hi
> mismatched interface file versions (wanted "7004", got "7003")
I don't quite understand - how did 7.0.4 come to be using packages from
7.0.3? The packages go into different directories don't they?
> Obviously, the ghc version is encoded into the .hi file and checked
> before using it, including the minor patch level. But it seems that this
> bit of information is not included in the calculation of the interface
> hash! So although the ABI hash did not change between 7.0.3 and 7.0.4,
> the package is broken.
> I see two solutions for this problem:
> a) (preferred) The ghc version number is not encoded in the .hi file
> any more. Instead, a version counter is used that is manually
> incremented if there has been an incompatible change to the interface –
> after all, not every minor release of ghc changes this format.
> b) The interface file version should be included in the hash
> generation, so that a package built against the base package of 7.0.3
> will clearly state that it does not work with the base package of 7.0.4
> and needs to be rebuild.
> (Actually, b) should be the case even if a) is done).
Perhaps we should factor the version into the ABI hash. But I'd like to
understand more about how things are going wrong for you - I think your
use case is one we hadn't considered.
More information about the Glasgow-haskell-users