How accessible is a dynamically-linked ghc?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How accessible is a dynamically-linked ghc?

Nicolas Frisby
  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?

  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?

Bonus question:

  3) How many platforms support Core plugins but not a dynamically linked
ghc?

I'm hoping the answer is "zero". The availability of a dynamically-linked
ghc looks good, according to the wiki pages I found. It's not so clear to
me regarding support on Windows.

Thank you for your time.

P.S. ? Here's the wiki pages I read. Their up-to-dateness is not clear to
me. Please let me know if you see that I missed something.

=== Core plugins

  http://ghc.haskell.org/trac/ghc/wiki/NewPlugins ? nub is 2 years old

=== building and using shared libraries (aka "dynamic libraries")

  http://ghc.haskell.org/trac/ghc/wiki/Platforms ? very much alive and
useful

  http://ghc.haskell.org/trac/ghc/wiki/Status/May13#Dynamiclinking ?
summarizes GHCI behavior

  http://ghc.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport ? 4
years old

  http://ghc.haskell.org/trac/ghc/ticket/5620 ? good info in comments; 1.5
years old

=== default behavior of an entire GHC installation

  http://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault ? 8 months old

  especially http://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault#Windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130710/88906218/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

How accessible is a dynamically-linked ghc?

Joachim Breitner-2
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.html and I?m happy to elaborate. In the former case: *shrug* ? should we?

Greetings,
Joachim


--
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130711/417768bf/attachment.pgp>

Reply | Threaded
Open this post in threaded view
|

How accessible is a dynamically-linked ghc?

Nicolas Frisby
On Thu, Jul 11, 2013 at 2:25 AM, Joachim Breitner
<mail at joachim-breitner.de>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.htmland 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130711/ada17f90/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

How accessible is a dynamically-linked ghc?

Austin Seipp-4
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>
> 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.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.
>
> Thanks.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



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


Reply | Threaded
Open this post in threaded view
|

How accessible is a dynamically-linked ghc?

Ian Lynagh-2
In reply to this post by Nicolas Frisby
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?

Reply | Threaded
Open this post in threaded view
|

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>