Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))
Edward Z. Yang
ezyang at mit.edu
Thu Jul 27 00:35:06 UTC 2017
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:
> 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.)
More information about the ghc-devs