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