...

...

-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

Probably, the executable hello is 1000 times larger than object one because some piece of library (including binary code for outputting a string) is linked to it. In small user programs the library code is usually the larger part. In large user programs, it will be the smaller part.

Serge Mechveliani

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