#4387: Huge executables with GHC 7
----------------------------------+-----------------------------------------
Reporter: daniel.is.fischer | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86 | Failure: Other
----------------------------------+-----------------------------------------
Comment(by simonmar):
Replying to [comment:30 rl]:
> I thought that `collect2` automates this. IIRC, it ploughs through all
object files looking for specific constructor symbols and then generates
and links in an additional module which calls those symbols and is, in
turn, called at start up. Wouldn't it be enough to simply make sure that
module initialiser symbols look like constructors and link with
`collect2`?
Right, and we're already doing that for the foreign export initailisers.
We could use this method for the profiling initialisers too, but it would
mean compiling a C stub file with every Haskell module. That may be the
only way though.
> We could introduce a package ghc-annotations which would only define the
annotation types and which both vector and ghc would depend on.
Presumably, linking in ghc-annotations would have no impact on binary
sizes. FWIW, I would be in favour of doing this anyway because I've had
several complaints about vector depending on package ghc.
I think this is a good plan. In the long term we should fix the
initialisers, but this gives us a short term workaround while we think
about the best way to handle initialisers.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4387#comment:34>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
