#5292: libHSghc exports more symbols than Windows can handle
---------------------------------+------------------------------------------
Reporter: batterseapower | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.0.3 | Keywords:
Testcase: | Blockedby:
Os: Windows | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime crash
---------------------------------+------------------------------------------
Comment(by duncan):
I find it hard to believe that we actually need >64k symbols. I would look
for ways to reduce unnecessary exports. This would also improve dynamic
linking performance (on Windows and other platforms).
The simplest thing is to check that for each .o, only the symbols
corresponding to module exports (manual or compiler-generated) are ending
up as DLL exports.
A more sophisticated approach would be to generate the DLL export list by
tracing the external visiblity of STG/CMM-level functions of the package
as a whole. Start from the exposed modules, take all exported functions
(manual or compiler-generated). For any with unfoldings, take the set of
functions mentioned in the unfoldings. Repeat this recursively. This
should be the full set of functions that could ever end up being
references from another package and thus requiring an exported symbol name
in the package's DLL. This analysis should be doable using the ghc-api
just looking at the .hi files for a compiled package, prior to linking the
DLL.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5292#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
