Use the compiler that built ghc for dynamic code loading, for cross-compiling
In a non cross-compiled stage 2 compiler, this coincides with what we do today, because the stage 1 implementation of GHC is the same as the stage 2 implementation. But in a cross-compiler, these are NOT the same: the cross-compiler's ghc library handles the package database in the target platform, whereas the compiler that built stage 2 (stage 1)'s ghc library handles the package database for the compiler's platform.
So, the correct architecture for supporting compiler plugins is that GHC should use the package-database/interface infrastructure from the compiler which built it (stage 1) to handle loading.
A few things to note:
- There is not a backwards-compatibility problem, because we can assume that stage 1 and stage 2 are built from the same codebase. In particular, this does NOT mean that TH/plugins start working on a stage 1 compiler. You have to have bootstrapped from the same codebase.
- Plugins (and even Template Haskell) have to be a bit more careful to take advantage of this. We cannot just assume that the package database for plugins is the same as the package database for compiling (revisiting #11244 (closed)). Template Haskell is even trickier: we should NOT be allowed to use regular imports in splices; they have to go through
TH_ONLYimports, c.f. #11377
- Can we actually link against the old version of
ghc? Yes we can! All we need is (1) for it to have been built with a different IPID, and (2) to use module renaming to rename the relevant modules to a different module name, so that we can import them without a conflict.
Stepping back, there have been two approaches for dealing with the problem of Template Haskell/compiler plugins not reliably working:
- Run the code in an external process run in the target code, or
- Fix GHC to load code which is appropriately built for the bootstrap platform.
While (1) offers a more uniform environment for developers, (2) is absolutely necessary in some situations when you need to load code in the same address space as GHC, e.g. as mentioned in https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html Thus, it seems worth pursuing both.