Dynamic libraries by default and GHC 7.8

Carter Schonwald carter.schonwald at gmail.com
Wed Dec 5 04:33:45 CET 2012


Agreed. I'd much rather never again problems in ghci + linking,
 Its one of the biggest sources of exotic bugs for new haskellers on OS X,
for all that i've never quite managed to ever pin down a simple test case
to replicate those problems

point being: ghci should do normal dynamic linking for reduced engineering
complexity + an end to "it doesn't work in ghci" woes that some folks
periodically enncount

+++++1

-Carter


On Tue, Dec 4, 2012 at 9:33 PM, Manuel M T Chakravarty <chak at cse.unsw.edu.au
> wrote:

> Simon Marlow <marlowsd at gmail.com>:
> >> This has some advantages and some disadvantages, so we need to make a
> >> decision about what we want to do in GHC 7.8. There are also some policy
> >> questions we need to answer about how Cabal will work with a GHC that
> >> uses dynamic libraries by default. We would like to make these as soon
> >> as possible, so that GHC 7.6.2 can ship with a Cabal that works
> >> correctly.
> >>
> >> The various issues are described in a wiki page here:
> >>     http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
> >
> > Thanks for doing all the experiments and putting this page together, it
> > certainly helps us to make a more informed decision.
> >
> >> If you have a few minutes to read it then we'd be glad to hear your
> >> feedback, to help us in making our decisions
> >
> > My personal opinion is that we should switch to dynamic-by-default on
> all x86_64 platforms, and OS X x86. The performance penalty for x86/Linux
> is too high (30%), and there are fewer bugs affecting the linker on that
> platform than OS X.
> >
> > I am slightly concerned about the GC overhead on x86_64/Linux (8%), but
> I think the benefits outweigh the penalty there, and I can probably
> investigate to find out where the overhead is coming from.
>
> I agree with your opinion.
>
> Firstly, correctness is more important than performance. (It's Haskell,
> after all.) Secondly, the RTS linker is an unnecessary time sink, and
> developer cycles are precious. Thirdly, when shipping production systems,
> people can always link statically to get best performance.
>
> Manuel
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121204/f941b96e/attachment.htm>


More information about the Glasgow-haskell-users mailing list