On Fri, Jul 12, 2013 at 12:56 PM, Ian Lynagh
From 7.8, the plan is for [dynamically-linked ghc] to be the default on platforms that support it.
snip
The plan is/was for this to be the only way to support GHCi, but see the discussion on http://ghc.haskell.org/trac/ghc/ticket/8039
Thanks, Ian; very helpful. I also just read through http://ghc.haskell.org/trac/ghc/ticket/3658 — I had incorrectly assumed the DynamicByDefault page subsumed it. That helped me understand people's concerns a lot better. Here's my updated status. I'm deciding between * Solution 1 — using the rts/Globals.c mechanism for `FastString.string_table`, or * Solution 2 — requiring a dynamically-linked ghc to (safely) use plugins that involve FastStrings. I prefer Solution 1, because * it handles any number of instances of libHSghc in a process, *regardless of how they got there*, and * it puts no constraints on the rest of the user's installation — use whatever kind of ghc you like. I have one remaining concern: in the eventuality in which ghci becomes its own dynamically-linked binary and ghc remains statically-linked, then my patch will be the only remaining use of the `rts/Globals.c` mechanism. (For the record, that mechanism is vastly simpler than the RTS linker…) We can cross that bridge if/when we come to it, though. I'm planning to push Solution 1 to HEAD this weekend, unless someone shouts at me politely. Thanks, everyone, for your input.