Cabal does not consider GHC ABI

[hasufell]

Cabal assumes that ABI is stable across ghc --numeric-version, both for the cabal store artifacts, as well as for the dist-newstyle/ artifacts.

However, this assumption is wrong. GHC has no ABI stability and two bindists of the same version, for the same architecture and platform can have diverging ABI.

One instance of this is https://gitlab.haskell.org/ghc/ghc/-/issues/21423

@andreasabel

[gbaz]

If I recall we decided that this was an issue that would be solved with the ghc build system -- in particular ghc distributions needed to calculate and store an abi-hash with their own bundled libraries?

[gbaz]

cc @bgamari who hopefully remembers this.

[hasufell]

@wz1000 was involved in some of the ABI hash generation stuff: haskell/haskell-language-server#2675 (comment)

But I can't find the so called ghc-abihash package from the linked MR anymore: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965

The HLS wrapper scripts just construct the ghc abi hash from the hashes of all boot libraries (ghc-pkg field <pkg> abi --simple-output). Cabal could do the same, but it would for sure be better if GHC has an API to query the ABI hash.

[jneira]

imho it is clear that ghc should be able to tell us its abi and no fix downstream all tools which depends on it
fortunately cabal nor cabal-install depends statically on ghc and users could workaround using a dedicated store or build dir if abi changes cause issues (iiuic not always is the case)

[hasufell]

imho it is clear that ghc should be able to tell us its abi and no fix downstream all tools which depends on

I'm not sure I follow. Figuring out the ABI is easy (as explained above), there's just no official API to query it for GHC, so you won't get cross-tool consistency. That doesn't really block fixing it, though.

users could workaround using a dedicated store or build dir if abi changes cause issues (iiuic not always is the case)

ABI breakages aren't easily visible to users, unless they hit obscure errors. So I don't think there's a reasonable workaround.

[mpickering]

To be clear the issue here is in particular object files, not the interface (.hi) files, which are safe to share across compilers with the same numeric version.

[jneira]

So the action would be replace the uses of ghc numeric version with the ghc abi hash?
So cabal would have a dedicated directory for each ghc abi hash in the store and build dirs?

[hasufell]

https://gitlab.haskell.org/ghc/ghc/-/issues/21590

[hasufell]

@phadej do you know if package ABI ever makes it into the hash?