Dynamic libraries and GHCi

[Simon Marlow]

We had planned to switch to using a dynamically-linked GHCi for 6.14.1 
(see http://hackage.haskell.org/trac/ghc/ticket/3658), which on the 
whole seems like the right direction to be heading in, since we reduce 
the dependence on our own RTS linker.

The dynamically-linked GHCi works, and passes all the tests.  It also 
starts up faster than the statically linked one, at least on Linux, 
possibly due to a combination of the system linker being faster than 
ours and it doing on-demand linking.  That's the good news.

But I've realised this transition won't be as easy as I thought. 
Currently if you build a package dynamically (Cabal's --enable-dynamic), 
then you get a completely separate build of the package, with its own 
interface files and so on - it's a "way", in the same sense as 
profiling.  This seemed obviously the sensible thing to do, since we 
really are compiling the code multiple times, and the results might be 
different.  However, it gives us a problem with GHCi.  If GHCi is 
dynamically linked, then it can only load object code that is compiled 
with -dynamic, because then the object code will be compiled against the 
right .hi files.

I see only three possibilities:

  - we make -dynamic the default.

  - we somehow make the two ways compatible.  This would probably
    entail compiling both versions at the same time, so we get
    the same Core, but running the code generator twice.

    I think there might be some technical problems with doing
    this, as we sometimes turn static data into dynamic data
    when compiling with -dynamic.  If we could work around this,
    though, the general idea would still require a lot of changes
    in build systems, Cabal, GHC and so on.

  - packages should have predictable & stable ABIs.  I've been
    wanting to do this for a long time, but we're not ready yet,
    and even so I hadn't planned to impose stable ABIs on every
    package - e.g. doing this for the base package would probably
    limit cross-module optimisation too much.

It's perhaps worth investigating the consequences of the first option, 
making -dynamic the default.  Cabal would have to --enable-dynamic by 
default - perhaps it would get an --enable-static that could even be 
*off* by default.

We would have to measure the performance implications carefully.  I know 
that right now the GC takes quite a severe performance hit (about 30% or 
so) when compiled with -fPIC on x86, due to losing the %ebx register.  I 
think that's unacceptable, but I haven't managed to fix it yet.

I don't have a clear idea for how to proceed, so I thought I'd describe 
the issues here and see if we can come up with a plan.

Cheers,
	Simon