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

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.

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.

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.

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.

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