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 > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs