libHSghc exports more symbols than Windows can handle
If you build GHC with shared libraries enables, the generated libHSghc.dll will export 65536 symbols. This is the limit that Windows DLLs can handle (the source of the limitation is that they use 16-bit integers to represent "ordinals").
Unfortunately, this means that the generated DLL is actually missing a ton of exports! Bad things happen at this point, including runtime crashes in GHCs linker. One interesting feature is that there seems to be a bug with GetProcAddress for modules that have filled up their export lists like this, so if hmod is a handle to the loaded DLL, GetProcAddress(hmod, "LocalAlloc") will succeed even though LocalAlloc is not exported by the DLL.
The number of symbols exported varies wildly depending on how you build the compiler. A "quick" build (from build.mk.sample) only exports 39k symbols, which is under the limit, but the kind of build that validate does ends up hitting the limits. (This difference was the source of some fun debugging confusion for me...)
Because of this bug, we won't be able to distribute a dynamically linked GHC on Windows. It is also preventing me from getting plugins06 to pass on Windows.
One workaround would be to build GHC with settings that result in less exported symbols until we get below the limit again -- i.e. export less unfoldings. This might adversely impact compiler performance, however.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |