Version 1 (modified by igloo, 4 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.

Current status

Unix-like platforms




Other platforms

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.

TicketAffects OS X x86_64?Affects OS X x86?Affects Linux x86_64?Affects Linux x86?Affects Windows x86_64?Affects Windows x86?Affects other platforms?
#781 GHCi on x86_64, cannot link to static data in shared libsnonoYESnononono
#1883 GHC can't find library using "short" namenonononoprobablyYESno
#2283 WIndows: loading objects that refer to DLL symbolsnonononoprobablyYESno
#3242 ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)nonononoprobablyYESno
#3654 Mach-O GHCi linker lacks support for a range of relocation entriesYESYESnonononono
#4244 Use system linker in GHCi to support alpha, ia64, ppc64nonononononoYES
#5062 Patch: Debug output for OS X linker and coding standard upgradesYESYESnonononono
#5197 Support static linker semantics for archives and weak symbolsYESYESYESYESYESYESYES
#5435 GHCi linker should run constructors for linked librariesYESYESYESYESYESYESYES
#6107 GHCi runtime linker cannot link with duplicate common symbolsYESYESYESYESYESYESYES
#7043 32-bit GHC ceiling of negative float SEGFAULT: 11noYESnonononono
#7056 GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'nonononoprobablyYESno
#7072 GHC interpreter does not find stat64 symbol on LinuxnonoYESnononono
#7097 linker fails to load package with binding to foreign librarynonononoprobablyYESno
#7103 Compiler panic, when loading wxc in GHCinonononoprobablyYESno
#7134 ghc- -> internal error R_X86_64_PC32nonononoYESnono
#7207 linker fails to load package with binding to foreign library (win64)nonononoYESnono
#7299 threadDelay broken in ghci, Mac OS XYESYESnonononono
#7357 GHC.exe gives an internal error while linking vector's Monadic.hsnonononoYESnono


There are some performance questions to consider before making a decision.

Other issues

Cabal support

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).

Other approaches

In #3658 there is some discussion of related design decisions etc.