On Wed, Nov 28, 2012 at 06:43:09AM +0000, Ganesh Sittampalam wrote: > On 27/11/2012 14:52, Ian Lynagh wrote: > > > GHC HEAD now has support for using dynamic libraries by default (and in > > particular, using dynamic libraries and the system linker in GHCi) for a > > number of platforms. > > > > This has some advantages and some disadvantages, so we need to make a > > decision about what we want to do in GHC 7.8. There are also some policy > > questions we need to answer about how Cabal will work with a GHC that > > uses dynamic libraries by default. We would like to make these as soon > > as possible, so that GHC 7.6.2 can ship with a Cabal that works > > correctly. > > > > The various issues are described in a wiki page here: > > http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault > > If I understand the problem on Windows correctly, you can use dynamic > libraries for ghci, but using them for compiled executables is difficult > because there's no good solution for having the compiled exe find its DLLs.
Right. > If so, does that mean that you intend to switch over ghci to dynamic and > build static+dynamic by default, or are you going to leave ghci as static? Leave ghci as static. > My general feeling about Windows is that it's ok for the end result to > be a little annoying, because Windows DLLs *are* annoying and it's > nothing to do with GHC. > > In particular I think in practice most Windows developers will have > admin rights and could live with the ghc installation and cabal install > having to be done as elevated operations. Where they weren't done with > admin rights, then ghc -o could warn the user that the DLLs need to be > copied locally (or even copy them itself and tell the user it happened). Personally, I would prefer the "C stub" option to that. > More generally, if you can implement the "half a plan" you mentioned > elsewhere in the thread for quickly building both static and dynamic > ways, then the combination of the ABI and performance issues mean that > I'm marginally in favour of keeping static linking as the default for > executables on all platforms, but building the dynamic libraries for ghci. That would solve the "installing libraries takes twice as long" problem, but not the "ghci can't load modules compiled with ghc -c" problem. Thanks Ian _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
