[GHC] #5987: Too many symbols in ghc package DLL

[GHC]

#5987: Too many symbols in ghc package DLL
---------------------------------+------------------------------------------
    Reporter:  igloo             |       Owner:                  
        Type:  bug               |      Status:  new             
    Priority:  highest           |   Milestone:  7.6.1           
   Component:  Compiler          |     Version:  7.5             
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
 In HEAD, the libHSghc DLL currently contains about 75000 symbols, but DLLs
 can only have about 65000 symbols. This means that when you try to run
 anything that uses the libHSghc DLL, references get resolved incorrectly
 and the GCer segfaults.

 Max ran into this before, and temporarily fixed it with:
 {{{
 commit dd391759500ab2b6abd23d502ade7ff8946c780f
 Author: Max Bolingbroke <batterseapower at hotmail.com>
 Date:   Wed Jul 6 18:01:02 2011 +0100

     Don't export the _info symbol for the data constructor worker bindings
 }}}
 but the number of symbols has since crept up.

 Three possible solutions:
  * Split the ghc package up into `ghc-base`, `ghc-codegen`, `ghc-
 nativegen`, etc.
  * Export fewer things. We'd first have to do this at the Haskell level
 (i.e. stop exposing some modules in the .cabal file; this may upset GHC
 API users), and then thread this info through so that we can tell the
 linker which symbols we do/don't want it to expose. Unfortunately, re-
 exports at the Haskell level mean that it isn't as simple as just not
 exporting anything from modules that aren't exposed.
  * Automatically split the package into 2 DLLs. The tricky bit here is
 that we'd need dependencies to go only in one direction, i.e. if
 libHSghc1.dll uses symbols from libHSghc2.dll, then libHSghc2.dll doesn't
 use any symbols from libHSghc1.dll. Ideally Cabal would have a way to do
 this automatically, and the GHC build system would use the split that it
 calculates. However, i don't think Cabal has enough info to do this
 currently.

 It would also be good if we can detect that building a DLL has gone wrong,
 and give an error.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5987>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler