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