Theoretically, ARM supports stage2 with the home-grown linker and a statically linked GHC, but last I understood, it can't build dynamically. That's because building the compiler with LLVM dynamically is unsupported, and ARM can only use the LLVM backend. There may be hope though; in commit a4212524, Peter Wortmann hints that LLVM may be able to dynamically link correctly now. I haven't tested it since the LLVM backend rewrite was merged in (and I should really get around to this.) On Thu, Jul 11, 2013 at 11:02 AM, Nicolas Frisby wrote:

On Thu, Jul 11, 2013 at 2:25 AM, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, den 10.07.2013, 14:42 -0500 schrieb Nicolas Frisby:

...

2) Are the major GHC distributors planning on distributing dynamically-linked ghc by default? GHC HQ, Haskell Platform, http://www.haskell.org/ghc/distribution_packages?

You are talking about the GHC binary itself, not about how GHC compiles the libraries and programs, right? For the latter case, answers for Debian (and Ubuntu) can be found in

http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023093.... and I’m happy to elaborate. In the former case: *shrug* – should we?

Yes, I was talking about the GHC binary itself. Even so, that is a very rich thread; thanks for the pointer.

I was asking for various reasons. I'm not casting a vote either way.

Thanks.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin - PGP: 4096R/0x91384671

On Fri, Jul 12, 2013 at 12:56 PM, Ian Lynagh 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.