How accessible is a dynamically-linked ghc?

Nicolas Frisby nicolas.frisby at
Fri Jul 12 22:55:14 CEST 2013

On Fri, Jul 12, 2013 at 12:56 PM, Ian Lynagh <ian at> wrote:

> From 7.8, the plan is for [dynamically-linked ghc] to be the default on
> platforms that
>  support it.

> The plan is/was for this to be the only way to support GHCi, but see the
> discussion on

Thanks, Ian; very helpful. I also just read through — 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: <>

More information about the ghc-devs mailing list