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