|Version 1 (modified by igloo, 3 years ago) (diff)|
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.
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.
There are some performance questions to consider before making a decision.
Currently released versions of Cabal/cabal-install don't handle dynamic-by-default GHCs well, as they don't pass the -static flag when building for static ways (as they assume that it is enabled by default). We should get fixed versions out as soon as possible (#7439).
In #3658 there is some discussion of related design decisions etc.