Dynamic libraries by default and GHC 7.8

[Ian Lynagh]

On Wed, Nov 28, 2012 at 01:34:22PM +0000, Ganesh Sittampalam wrote:
> On 28/11/2012 13:13, Ian Lynagh wrote:
> 
> >> 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.
> 
> Can't ghc -c also produce both static and dynamic objects?

That's true, it could. Simon will point out that build systems will
need updating if we start generating more/different files, but perhaps
the pain would be worthwhile.


I've been thinking about how to actually implement the half-plan. How
about this? (don't worry about the names I've used for things for now):

* Add a new way, "dynstatic".
  Compiling Foo this way makes
    Foo.ds_hi
    Foo.ds_s_o -- static
    Foo.ds_d_o -- dynamic
  and by default links statically. There's a flag to make it link
  dynamically instead.

* When compiling things the dynstatic way, all dependencies must be
  compiled the dynstatic way
* When compiling things the static way, dependencies can be
  compiled either the static or the dynstatic way
* When compiling things the dynamic way, dependencies can be
  compiled either the dynamic or the dynstatic way

* Cabal compiles dynstatic by default
* ghc compiles dynstatic (linking statically) by default
* ghci uses dynamic libraries on all platforms

* If we are worried about performance of the compiler, then ship ghc as
  a static binary and ghci as a separate dynamic binary. The size of the
  two combined is only 2-3% larger than just the static binary.


Thanks
Ian