Rebuilding ghc changes interface hashes?

[Simon Marlow]

On 09/04/11 06:16, Joachim Breitner wrote:
> Hi,
>
> Am Freitag, den 08.04.2011, 22:00 +0200 schrieb Matthias Kilian:
>> On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
>>> I still have to find my noticeses about wether cBooterVersion affects
>>> more than only the ghc lib.
>>
>> Did a quick test the other day; bootstrapping ghc-7.0.3 from
>> ghc-6.12.3 with two different VERSION_DATE files. The only visible
>> change was in the ghc library, so this part indeed isn't worth any
>> work.
>
> This is one of the changes causing a break in the base library. "-" is
> bootstrapped with 7.0.2, "+" was bootstrapped with 6.12.
>
> # diff -u<(ghc --show-iface /usr/lib/ghc-7.0.2/base-4.3.1.0/GHC/List.hi)<(ghc --show-iface /other/usr/lib/ghc-7.0.2/base-4.3.1.0/GHC/List.hi)
> --- /dev/fd/63	2011-04-09 05:14:12.454269915 +0000
> +++ /dev/fd/62	2011-04-09 05:14:12.454269915 +0000
> @@ -5,8 +5,8 @@
>   Way: Wanted [],
>        got    []
>   interface base:GHC.List 7002
> -  interface hash: 87193984226122c2dd5964fd86876196
> -  ABI hash: 8d7faf049b24c406583f0286cc44d7db
> +  interface hash: d8ee4b841dafe12780c3b173e214b5c7
> +  ABI hash: 180a90cd1355a939180d28fcca979825
>     export-list hash: 0c27906a7932ade6018f397c78520a54
>     orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e
>     where
> @@ -151,7 +151,7 @@
>                          case @ a ds of wild { [] ->  z : x xs ->  lgo (f z x) xs }
>                      } in
>                      lgo z0 xs0) -}
> -4314014978c443774e83654e714a6768
> +a018d005d4132f400d13b973d8352563
>     foldr1 :: forall a. (a ->  a ->  a) ->  [a] ->  a
>       {- Arity: 2, Strictness: LS,
>          Unfolding: (\ @ a ds :: a ->  a ->  a ds1 :: [a] ->
> @@ -161,9 +161,9 @@
>                        ->  case @ a ds2 of wild1 {
>                             [] ->  x
>                             : ipv ipv1
> -                          ->  ds x (GHC.List.foldr1_$sfoldr1 @ a ipv ipv1 ds) } }) -}
> -7e3de2c9e0866b189d8f94b9801e6793
> -  foldr1_$sfoldr1 :: forall a. a ->  [a] ->  (a ->  a ->  a) ->  a
> +                          ->  ds x (GHC.List.foldr1_$sfoldr1 @ a ds ipv ipv1) } }) -}
> +68a72d0de3128a684265d8108a56fd7b
> +  foldr1_$sfoldr1 :: forall a. (a ->  a ->  a) ->  a ->  [a] ->  a
>       {- Arity: 3, HasNoCafRefs, Strictness: LLL -}
>   328ef6e4bc937a0ad2498240a9327c37
>     foldr2 :: forall a b c. (a ->  b ->  c ->  c) ->  c ->  [a] ->  [b] ->  c
> @@ -489,10 +489,10 @@
>                        r :: b ->
>                      c (f x y) r) -}
>   "SC:GHC.List.foldr10" [ALWAYS] forall @ a
> -                                      sc :: a
> -                                      sc1 :: [a]
> -                                      sc2 :: a ->  a ->  a
> -  GHC.List.foldr1 @ a sc2 (GHC.Types.: @ a sc sc1)
> +                                      sc :: a ->  a ->  a
> +                                      sc1 :: a
> +                                      sc2 :: [a]
> +  GHC.List.foldr1 @ a sc (GHC.Types.: @ a sc1 sc2)
>     = GHC.List.foldr1_$sfoldr1 @ a sc sc1 sc2
>   "all/build" [ALWAYS] forall @ a
>                               p :: a ->  GHC.Bool.Bool
>
>
> So something about the order of arguments changed. I don’t see how that
> should be influenced by the bootstrapping compiler, but I hope it is –
> if it were not any rebuild of ghc would risk changing the ABI hashes...

That's right, the ABI hashes are not guaranteed to be stable, and in 
practice do change unpredictably.  While this doesn't affect 
correctness, I realise it's a problem for you, and it's something we'd 
like to fix.  The case above looks like a new one I didn't know about, 
so I've added it to the wiki.

In fact, I'm pretty impressed that we manage to get the same hashes even 
sometimes.  Do you have any idea how many bits have to be in the right 
order for that to happen :-)

Cheers,
	Simon