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
>
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
