Dynamic libraries by default and GHC 7.8

[Ganesh Sittampalam]

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.

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?

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).

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.

Cheers,

Ganesh