Oversized libraries

[Simon Marlow]

On 14/12/2010 16:33, Audrius Šaikūnas wrote:
> Hello,
>
> I've noticed that libraries that are compiled even with -dynamic are
> really huge:
> libHScairo-0.12.0-ghc6.12.1.so - 1.4 M
> libHSgio-0.12.0-ghc6.12.1.so - 1.6 M
> libHSgtk-0.12.0-ghc6.12.1.so - 14 M
>
> (ldd confirms that these libraries are really linked dynamically with
> the rest of the world)
>
> just to name a few. All of them are striped with "strip -s".
> At this point *bindings* to C libraries are larger that the libraries
> themselves, which I find unacceptable.
 >
> So I decided to dig a bit deeper and when examining cairo-0.12.0 I found
> that Types.o object file consumes 1.5 MB. So I "cleaned" up Types.hs and
> tried to compile it separately from the rest of the library:
>
>   % ghc -c Types.hs&&  ls -lh | grep Types.o
> -rw-r--r-- 1 angel angel  69K 2010-12-14 18:24 Types.o
>   % rm Types.o
>   % ghc -c Types.hs -O&&  ls -lh | grep Types.o
> -rw-r--r-- 1 angel angel 1.1M 2010-12-14 18:25 Types.o
>
> So adding -O when compiling Types.hs makes the size of object file jump
> from 69K to 1.1M. Just think about it - the file contains *two* *enums*
> and nothing more. And yet it twice as large as a full-blown application
> like gedit.
>
> So I would like to ask you whether such behavior is known and should
> such this be considered as a bug?

This particular example seems to be fixed, at least with the current HEAD:

$ ghc -O -c en.hs
$ ll en.o
-rw-rw-r-- 1 simonmar GHC 84248 2010-12-14 16:47 en.o
$ size en.o
    text    data     bss     dec     hex filename
   23210    3680       0   26890    690a en.o

But if you do find a case of code bloat, by all means file a bug and 
we'll look into it.

Cheers,
	Simon