7.8 Release Update

[Edward Z. Yang]

Erm, I forgot to mention that profiling would only be enabled if
the user asked for it.

Yes, we will be producing two sets of objects by default. This is what
the -dynamic-too flag is for, no?  I suppose you could try to compile
your static executables using -fPIC, but that would negate the performance
considerations why we haven't just switched to dynamic for everything.

Edward

Excerpts from Johan Tibell's message of Mon Sep 09 16:15:45 -0700 2013:
> That sounds terrible expensive to do on every `cabal build` and its a
> cost most users won't understand (what was broken before?).
> 
> On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> > If I am building some Haskell executable using 'cabal build', the
> > result should be *statically linked* by default.
> >
> > However, subtly, if I am building a Haskell library, I would like to
> > be able to load the compiled version into GHCi.
> >
> > So it seems to me cabal should produce v, dyn (libs only, not final
> > executable) and p ways by default (but not dyn_p).
> >
> > Edward
> >
> > Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 2013:
> >> Hi,
> >>
> >> > Kazu (or someone else), can you please file a ticket on the Cabal bug
> >> > tracker [1] if you think that this a Cabal bug?
> >>
> >> I'm not completely sure yet.
> >>
> >> GHCi 7.8 uses dynamic linking. This is true.
> >>
> >> So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they
> >> supposed to use dynamic linking? Or, static linking?
> >>
> >> If dynamic linking is used, GHC should provide dynamic libraries for
> >> profiling.
> >>
> >> If static linking is used, cabal-install should stop using dynamic
> >> libraries for profiling.
> >>
> >> And of course, I can make a ticket when I'm convinced.
> >>
> >> P.S.
> >>
> >> Since "doctest" uses GHCi internally, I might misunderstand GHC 7.8
> >> uses dynamic linking. Anyway, I don't understand what is right yet.
> >>
> >> --Kazu
> >>
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs