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,
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
<nicolas.frisby at gmail.com> wrote:
> On Thu, Jul 11, 2013 at 2:25 AM, Joachim Breitner <mail at joachim-breitner.de>
>> 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.html >> 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.
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs >
On Wed, Jul 10, 2013 at 02:42:27PM -0500, Nicolas Frisby wrote:
> 1) How much effort does it take for a user to install a
> dynamically-linked ghc executable on Tier 1 platforms? Just download the
> source and set DYNAMIC_GHC_PROGRAMS=YES?
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.