g++ produces big binaries despite small project

Question

Probably this is a common question. In fact I think I asked it years ago... but I can't remember the answer.

The problem is: I have a project that is composed of 6 source files. All of them no more than 200 lines of code. It uses many STL containers, stdlib.h and iostream. Now the executable is around 800kb in size.... I guess I shouldn't statically link libraries. How to do this with GCC? And in Eclipse CDT?

EDIT: As I responses away from what I want I think it's the case for a clarification. What I want to know is why such a small program is so big in size and what is the relationship with static, shared libraries and their difference. If it's a too long story to tell feel free to give pointers to docs. Thank you

Answer 1

If you give g++ dynamic library names, and don't pass the -static flag, it should link dynamically.

To reduce size, you could of course strip the binary, and pass the -Os (optimize for size) optimization flag to g++.

Answer 2

Use -O3 and -s flags to produce the most optimized binary. Also see this link for some more information.

If you are building for Windows, consider using the Microsoft compiler. It always produces the smallest binary on that platform.

Answer 3

Eclipse should be linking dynamically by default, unless you've set the static flag on the linker in your makefile.

In response to your EDIT :

-when you link statically, the executable contains a full copy of each library you've linked to.
-when you link dynamically, the executable only contains references and hooks to the linked libraries, which is a much much smaller amount of code.

Answer 4

The executable has to contain more than just your code.

At the very least, it contains some startup code, setting up the environment and if necessary, loading any external libraries, before the program launches.

If you've statically linked the runtime library, you also get that included in your executable. Otherwise you only get a small stub, just big enough to redirect system calls to the external runtime.

It may, depending on compiler settings also include a lot of debugging info and other non-essential data. If optimizations are enabled, that may have increased code size as well.

The real question is why does this matter? 800KB still fits easily on a floppy disk! Most of this is a one-time cost. it doesn't mean that if you write twice as much code, it'll take up 1600KB. More likely, it'll take 810KB or something like that.

Don't worry about one-time startup costs.

Answer 5

One thing to remember is that using the STL results in having that extra code in your executable even if you are dynamically linking with the C++ library. This is by virtue of the fact that the STL is a bunch of templates that aren't actually compiled until you write and compile your code. Since the library can't anticipate what you might store in a container, there's no way for the library to already contain the code for that particular usage of the container. Same goes with algorithms and everything else in the STL.

I'm not saying this is definitely the reason your executable is so much larger than you expect. But it may be a factor.

Answer 6

The size usually results in static libraries being linked into your application.

You can reduce the size of the compiled binary by compiling to RELEASE versions, with optimizations to binary size.

Another source of executable size are the libraries. You said that you don't use external libraries, except for STD, so I believe you're including the C Runtime with your executable, ie, linking statically. so check for dynamic linking.

IMO you shouldn't really worry about that, but if you're really paranoid, check this: Smallest x86 ELF Hello World