I'm curious

[PDEE]

well i finally got my codeblocks nightly onto suse 10.1. Now i was trying it out and testing to see if all was well. I'm not as advanced as most of you guys at programming. Why on a windows system when building a simple program to test codeblocks with a hello world program i get an exe of nearly 300Kb? Now on the linux one it is only 8Kb, they are the same programs. All the settings are the same. What makes it different? You are probably wondering why i ask, well i would like to know as much as i can about why things work the way they do programming wise.

Anyway, like i said, i'm curious.

Thank You
PDEE

[takeshimiya]

On linux (GCC), you're linking with stdc++ dinamically.
On windows (GCC MinGW), you're linking to it statically.

C++ programs using the Standard Template Library (ie/ #include <iostream>) cause a large part of the library to be statically linked into the binary. The need to statically link the stdc++ into the binary is two fold. First MSVCRT.dll does not contain C++ stdlib constructs. Second the legal implications of generating a libstdc++.dll are restricted by the licensing associated with the library. If you wish to keep your file size down use strip to remove debugging information and other verbatim found in the binary.

strip --strip-all SOMEBINARY.exe

[sethjackson]

On linux (GCC), you're linking with stdc++ dinamically.
On windows (GCC MinGW), you're linking to it statically.

C++ programs using the Standard Template Library (ie/ #include <iostream>) cause a large part of the library to be statically linked into the binary. The need to statically link the stdc++ into the binary is two fold. First MSVCRT.dll does not contain C++ stdlib constructs. Second the legal implications of generating a libstdc++.dll are restricted by the licensing associated with the library. If you wish to keep your file size down use strip to remove debugging information and other verbatim found in the binary.

strip --strip-all SOMEBINARY.exe

* Sigh *

Funny thing is on my OpenBSD 3.9 system with GCC 3.4.5 + patches Hello World is ~163 KB.

Anyways I wish MinGW could produce smaller executables without the strip command.....

[Ceniza]

Anyways I wish MinGW could produce smaller executables without the strip command.....

Me too

It's a shame they use that old MSVCRT DLL and the project to code a replacement died. It's also a shame trying to compile GCC to produce DLLs didn't work (it was totally ignored and produced the same result).

In fact, in my old days of #allegro, that was a thing some people didn't like about using C++.

[takeshimiya]

The good thing is that there is always stlport.
You can link indeed to it dynamically with MinGW.

The OGRE guys use (in Windows) stlport over stdc++ for a couple of reasons. I've tested it and works without problems.

[PDEE]

Thanks Takeshi.

Moving from windows to linux is all different for me. Well at least i know why now. When i strip the file i get 4Kb  :shock:. I'm going to read up some more on this.

Thank You
PDEE

[sethjackson]

The good thing is that there is always stlport.
You can link indeed to it dynamically with MinGW.

The OGRE guys use (in Windows) stlport over stdc++ for a couple of reasons. I've tested it and works without problems.

I tried that. However with Digital Mars (didn't try it with MinGW) it produced about the same size executable as MinGW with stdc++....... I may have to give it another go around.

[takeshimiya]

The good thing is that there is always stlport.
You can link indeed to it dynamically with MinGW.

The OGRE guys use (in Windows) stlport over stdc++ for a couple of reasons. I've tested it and works without problems.

I tried that. However with Digital Mars (didn't try it with MinGW) it produced about the same size executable as MinGW with stdc++....... I may have to give it another go around.

Which makes perfect sense, since the stlport bundled with DMars is compiled statically.
But if you compile stlport and link to it dinamically, the situation will change :wink:

[sethjackson]

The good thing is that there is always stlport.
You can link indeed to it dynamically with MinGW.

The OGRE guys use (in Windows) stlport over stdc++ for a couple of reasons. I've tested it and works without problems.

I tried that. However with Digital Mars (didn't try it with MinGW) it produced about the same size executable as MinGW with stdc++....... I may have to give it another go around.

Which makes perfect sense, since the stlport bundled with DMars is compiled statically.
But if you compile stlport and link to it dinamically, the situation will change :wink:

Oh ok I see.