How accessible is a dynamically-linked ghc?

[Nicolas Frisby]

On Fri, Jul 12, 2013 at 12:56 PM, Ian Lynagh <ian at well-typed.com> wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130712/b2645012/attachment.htm>