Reinstalled GHC should be completely ABI compatible. This should actually not be difficult to achieve, since we already rely on this in the GHC build system: we assume that ghc-stage1 generated hi files can be compatibly read and used by ghc-stage2. Excerpts from Joachim Breitner's message of 2017-07-24 15:04:21 -0400:
Hi,
Am Montag, den 24.07.2017, 12:24 +0200 schrieb Herbert Valerio Riedel:
Also, I'd like to know if you can think of reasons why or situations when the reinstalled lib:ghc wouldn't work; or other reasons why this is a bad idea.
I’d am mostly worried about ABI compatibility. Will the .hi files written by the compiler be readable by some tool that was built with an upgraded ghc? Which dependencies can affect the binary format (if any)?
Or will the rebuilt ghc get its own, randomly generated “GHC version” (similar to a development build where the build date is part of the GHC version) and hence never try to interact with build artifacts created from the host ghc?
Also, if we can `cabal install ghc-the-library`, can we also `cabal install ghc-the-program`, possibly at a different version? (It wouldn’t be normally usable without bootstrapping a RTS and base library, but it would be a step.)
Greetings, Joachim