enormous executable
Simon Marlow
simonmar@microsoft.com
Mon, 1 Oct 2001 09:55:11 +0100
> > > -rwxr-xr-x 1 willem users 201453 Sep 29 09:55 hello
> > > -rw-r--r-- 1 willem users 51 Sep 29 09:54 hello.hs
> > > -rw-r--r-- 1 willem users 1468 Sep 29 09:55 hello.o
> >=20
> > Probably, the executable hello is 1000 times larger than object
> > one because some piece of library (including binary code for=20
> > outputting a string) is linked to it.
> > In small user programs the library code is usually the larger=20
> > part. In large user programs, it will be the smaller part.
> >
> > Serge Mechveliani
>=20
> I think so too, but what I'm surprised about is that GHC apparently
> can't use printing functions and all those other things I saw in
> `strings hello`, for example things about sockets, forks and file IO,
> from a library instead of compiling it into the 'hello' binary.
We don't have support for shared libraries under Unix at the moment. It
has been investigated at various times in the past, and I believe the
story is that we couldn't do it without at least losing some performance
(more performance loss than you get from compiling C into a shared
library).
So what you're seeing is static linking in action. We do have some
hacks in our library building to "split" objects into small chunks so
that static linking doesn't result in *huge* binaries (see the
-split-objs flag), but this isn't being used in GTK+HS, hence the 2Mb
binaries.
Cheers,
Simon