Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,250
    • Issues 5,250
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 572
    • Merge requests 572
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5292
Closed
Open
Issue created Jul 02, 2011 by batterseapower@trac-batterseapower

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking