|Version 75 (modified by thoughtpolice, 17 months ago) (diff)|
Release plans for GHC 7.8
See recent ghc-devs posting GHC 7.8 Release Status & Schedule for latest timeline.
We would like to fix all of the high and highest priority tickets in the 7.8.1 milestone, but there are currently a lot of them so this seems optimistic. Please feel free to take a ticket and help us!
Completed new features
The features already completed are documented in the release notes: docs/users_guide/7.8.1-notes.xml
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:
- -dynamic-too doesn't work on Windows (#8228)
- 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.)
- 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.