Completed new features

Pending things to completion

Austin Seipp needs to upload the primops compatibility package for 7.8. This is is easy: mostly a copy of compiler/utils/ExtsCompat64.hs into a Cabal package. See also ​the compatibility module page. In progress.

Austin also still has a lingering patch for #7602 to fix a large OS X performance regression, but it's still not merged. This is because the thread-local storage implementation changed in OS X Mavericks, requiring more investigation.

-XTemplateHaskell should now imply -dynamic-too, based on the discussions in #8180. Austin is attempting to fix this by switching it on during module loading but it doesn't quite work yet.

Dynamic GHCi (#3658). This is working in HEAD, and enabled if DYNAMIC_GHC_PROGRAMS=YES, which causes GHC itself to be built dynamically. Currently it's enabled by default if dynamic libraries are supported, except for FreeBSD and Windows.
On FreeBSD the reason it's disabled is due to a bug in FreeBSD's rtld. This has been fixed, but we're waiting for the fix to make it into releases. This might be in time for 7.8, but certainly will be for 7.10. See #7819.
On Windows, there are a few problems:

Because of #8228, GHC is a bit nerfed in using lots of RAM - see the discussion in #7134. We should fix -dynamic-too to knock out two birds with one stone (fix #7134 and enable using lots of RAM.)

(Related but not critical: we have too many DLL symbols, and are very close to the limit (#5987). Linking also takes a long time (#8229))
The plan is/was to use dynamic GHCi on as many platforms as possible in 7.8, and to remove support for non-dynamic-ghci in HEAD soon after. See discussion in #8039, however.

Windows is becoming increasingly weird. It seems that with ./validate settings, a 32bit GHC built using the MSYS2 instructions mysteriously segfaults inside the stage2 compiler. But a 64bit GHC seems to work OK. But then as Austin was writing this it broke mysteriously, seemingly with no intervention.

Also, it seems as if -dynamic actually is broken in some weird way on Windows. During my (Austin) investigation into #8228, compiling a simple dynamic executable seems to result in segfaults. The most bizarre part is the .exe generated with -dynamic seems to depend on both libHSrts.dll and libHSrts_thr.dll! Without either in a place where the Windows linker can find it, the executable fails to start. Austin believes this is possibly the culprit (symbols may somehow get confused based on loading order,) but he doesn't know why -dynamic on windows seems to cause a dependency on both the threaded and non-threaded runtime.