[Haskell-beginners] GHC-generated executables size

[.]

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
> >
>