[GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling

[GHC]

#11378: Use the compiler that built ghc for dynamic code loading, for cross-
compiling
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  lowest         |         Milestone:  ⊥
          Component:  Template       |           Version:  7.11
  Haskell                            |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 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:

 1. 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.
 2. 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). Template Haskell is even trickier: we should NOT be allowed to
 use regular imports in splices; they have to go through `TH_ONLY` imports,
 c.f. #11377
 3. 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:

 1. Run the code in an external process run in the target code, or
 2. 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11378>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler