7.8 Release Update

[Kazu Yamamoto ( 山本和彦 )]

Hi,

Now I understand what is right and why I misunderstood.

- GHC 7.8 provides three kinds of libraries:
     - static libraries
     - dynamic libraries
     - static libraries for profiling
- GHCi uses dynamic libraries.
- Programs complied with GHC 7.8 use static libraries.
- When a library package is complied, both static one and dynamic
  one are created.
- When "-p" or "--enabling-executable-profiling" are specified to
  cabal, static libraries for profiling are also created and used.

So, we don't have to specify "--enable-shared"/"--disable-shared" to
cabal in normal situation.

There is no bug. Just I misunderstood.

* Why did I misunderstand that programs are linked dynamically?

I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally.
At the beginning, doctest cannot pass many tests if "--enable-shared"
is not specified. This was fixed:

	https://github.com/sol/doctest-haskell/issues/58

Now, "--enable-shared" is not necessary even for doctest.

* Why did I misunderstand that compiling programs for profiling fails?

I specified --ghc-options="-prof -fprof-auto". "-prof" lets GHC 7.8
to produce both static and dynamic libraries for profiling. This
resulted in build failure.

Right procedure for profiling are:

% cabal install -p --enable-executable-profiling --ghc-options="-fprof-auto" -j3

or

% cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3
% cabal configure --enable-executable-profiling
% cabal build

--Kazu

> On 09/09/13 08:14, Edward Z. Yang wrote:
>> Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08
>> 19:36:19 -0700 2013:
>>> ----
>>> % make show VALUE=GhcLibWays
>>> make -r --no-print-directory -f ghc.mk show
>>> GhcLibWays="v p dyn"
>>> ----
>>
>> Yes, it looks like you are missing p_dyn from this list. I think
>> this is a bug in the build system.  When I look at ghc.mk
>> it only verifies that the p way is present, not p_dyn; and I don't
>> see any knobs which turn on p_dyn.
>>
>> However, I must admit to being a little confused; didn't we abandon
>> dynamic by default and switch to only using dynamic for GHCi (in which
>> case the profiling libraries ought not to matter)?
> 
> I think Kazu is saying that when he builds something with profiling
> using cabal-install, it fails because cabal-install tries to build a
> dynamic version too.  We don't want dyanmic/profiled libraries
> (there's no point, you can't load them into GHCi).  Perhaps this is
> something that needs fixing in cabal-install?
> 
> Cheers,
> 	Simon
>