How accessible is a dynamically-linked ghc?
nicolas.frisby at gmail.com
Fri Jul 12 22:55:14 CEST 2013
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.
> 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
* 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...
More information about the ghc-devs