7.8 Release Update
simonpj at microsoft.com
Thu Sep 12 18:35:23 UTC 2013
Is this something that could be clarified in GHC's documentation? Patch?
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kazu
| Sent: 12 September 2013 04:43
| To: glasgow-haskell-users at haskell.org; ghc-devs at haskell.org
| Subject: Re: 7.8 Release Update
| 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:
| 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
| % cabal install -p --ghc-options="-fprof-auto" --only-dependencies -j3
| % cabal configure --enable-executable-profiling
| % cabal build
| > 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
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs