Dynamic GHC programs
Currently, GHCi doesn't use the system linker to load libraries, but instead uses our own "GHCi linker". Unfortunately, this is a large blob of unpleasant code that we need to maintain, it already contains a number of known bugs, and new problems have a tendency to arise as new versions of OSes are released. We are therefore keen to get rid of it!
There is some benefit (in terms of both bugs fixed and code removed) to removing it for a particular platform (e.g. Linux(elf)/x86), more benefit to removing it for a particular OS (e.g. Linux(elf)), but the most benefit is gained by removing it entirely.
Our solution is to switch GHCi from using the "static way", to using the "dynamic way". GHCi will then use the system linker to load the .dll for the library, rather than using the GHCi linker to load the .a.
This is controlled by the DYNAMIC_GHC_PROGRAMS build system variable. If it is YES, then we build ghci the dynamic way. If it is NO then we build it the static way.
Build times, and -dynamic-too
The default way, as used by ghc Foo.hs for example, will remain the vanilla (static) way. But GHCi uses dynamic libraries, so we need to build all the libraries both ways (both in the GHC build, and when the user cabal-installs 3rd party libraries). This would double the compilation time needed.
We have therefore added a -dynamic-too flag. This allows a single invocation of GHC to build both the vanilla and dynamic ways. The GHC build system uses this if DYNAMIC_TOO is YES, and Cabal HEAD uses it if the compiler supports it.
Both DYNAMIC_GHC_PROGRAMS and DYNAMIC_TOO work on unix-like platforms. They are enabled by default provided the platform supports dynamic libraries.
On Windows, DYNAMIC_GHC_PROGRAMS works, but DYNAMIC_TOO doesn't. Currently, DYNAMIC_GHC_PROGRAMS is disabled, although it could be enabled at the expense of longer compilation times. Linking time is also significantly higher for the dynamic way, but we aren't aware of any way to improve that.
We do not know the situation with other platforms, such as iOS and Android. We do not know whether they have a system loader that they can use, or whether it would be useful to keep the GHCi linker around for them.
As well as the ticket for implementing dynamic GHCi (#3658), the table below lists the related tickets and the platforms that they affect. Most, if not all, of these would be immediately fixed by switching to dynamic GHCi.
Currently released versions of Cabal/cabal-install don't handle dynamic GHCi well. In particular, if a library uses Template Haskell, then Cabal will build the ways in the wrong order, so compilation will fail. Cabal in HEAD handles it properly.
In #3658 there is some discussion of related design decisions etc.