Hi Daniel, thanks for the explanations. I have tried reinstalling with cabal --reinstall gtk, having set split-objs: True in ~/.cabal/config before. However, the compile yielded a single .o file again, and recompiling and re-linking my little program does not change its size ... Any other idea what I might be doing wrong? Also, I saw in the ghc documentatio about -split-objs that one should only use it "if you know exactly what you're doing". Do you know what the caveats are? Thanks again, Christian On Sat, 2010-10-16 at 13:23 +0200, Daniel Fischer wrote:
On Saturday 16 October 2010 12:26:00, . wrote:
Hi, I was playing around with ghc again, and I was wondering what makes the executables so large and how I could make them smaller (strip works, but is there anything more I can do?) More specifically, I am compiling a program that uses the GTK+ bindings, HDBC, and some things from Prelude. The program simply displays a window, and reads and writes values from/into a data base file. Not much, really. Anyway, the program size is 20MB without stripping, and 10MB after stripping ...
Any hints?
Two things spring to mind (in addition to the static linking mentioned by Aleksandar).
1) If you didn't compile the packages with -split-objs, when you use one function from a module, the entire object file for the module is linked in. For packages with many modules or many dependencies, that adds up pretty fast.
If you set
in your ~/.cabal/config, packages installed via cabal-install (the cabal executable) will be built with -split-objs and only the needed functions will be linked in (at least if you compile your programmes with optimisations, I don't know whether -O0 uses split object files or the monolithic ones). (Downside: building the packages takes longer, duh; and you need more disk space for monolithic+split object files, duh again).
2) If it's not (only) that, it's probably the same effect as discussed in http://hackage.haskell.org/trac/ghc/ticket/4387
Simon (PJ) says: "Every module has a module-initialisation routine. Apart from initialising the module, it calls the module-initialisation routine for each imported module. So if M imports module SpecConstr from package ghc, then the module-initialisatin routine for M will call the initialisation routine for SpecConstr. Even though nothing from SpecConstr is ultimately used."
So if you import a module (you don't even need to use anything from it) which transitively imports a lot of modules, you get a ton of module- initialisation routines. People are thinking about how to handle this best (since it affects the vector package, on which a lot of other packages depend, it's not unimportant).
Thanks and good night for now .. Christian