Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • 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 4,830
    • Issues 4,830
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 447
    • Merge requests 447
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #5987

Closed
Open
Created Apr 03, 2012 by Ian Lynagh <igloo@earth.li>@trac-igloo

Too many symbols in ghc package DLL

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.

Trac metadata
Trac field Value
Version 7.5
Type Bug
TypeOfFailure OtherFailure
Priority highest
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system Unknown/Multiple
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking