Changes between Version 74 and Version 75 of Status/GHC-7.8


Ignore:
Timestamp:
Jan 7, 2014 2:59:29 PM (14 months ago)
Author:
thoughtpolice
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Status/GHC-7.8

    v74 v75  
    1414[[GhcFile(docs/users_guide/7.8.1-notes.xml)]] 
    1515 
    16 == Pending new features == 
     16== Pending things to completion == 
    1717 
    18 The following **new** features are planned for 7.8 **but have not yet made it**. They are at varying degrees of completeness, and may not all make it in. 
    19  
    20  * Austin Seipp needs to upload the primops compatibility package for 7.8. This is mostly a copy of `compiler/utils/ExtsCompat64.hs` into a Cabal package. See also [http://www.haskell.org/haskellwiki/Compatibility_Modules the compatibility module page]. '''In progress'''. 
    21  
    22  * Austin Seipp needs to merge a patch from Ben Gamari to fix LLVM + dynamic linking. 
     18 * 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 [http://www.haskell.org/haskellwiki/Compatibility_Modules the compatibility module page]. '''In progress'''. 
    2319 
    2420 * 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. 
    2521 
     22 * `-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. 
     23 
    2624 * 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. 
    2725   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. 
    28    On Windows, there are a couple of build time annoyances: `-dynamic-too` doesn't work on Windows (#8228), and linking takes a very long time when dynamic linking is used (#8229). There's no technical reason why it couldn't be enabled, though. 
     26   On Windows, there are a few problems: 
     27    * `-dynamic-too` doesn't work on Windows (#8228) 
     28    * 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.) 
     29   (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)) 
    2930   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. 
     31 
     32 * 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. 
     33  
     34 * 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.