Huge MinGW Libraries!!

[PS3-690]

Hi,

why are the libraries built with MinGW so huge?

e.g.
sfml-system.dll built with MinGW - 500 KB
sfml-system.dll built with MSVC - 13KB

And what are these files ending with *-d.dll and *-d.dll
(example: sfml-window-d.dll) ??

greets,
PS3-690

[Avency]

The -d libraries are the debug libraries.
In general, debug libraries tend to be bigger than the release ones.
About the MinGW binaries being bigger than the msvc:
MinGW probably links some static runtimes whereas msvc mainly uses dynamic linking and presumes that the user has the msvc runtimes already installed (you can also link the msvc runtimes statically (I think?) even if this might not be the best idea).
I'm not sure about this, though.

[PS3-690]

I found two ways to compile the sfml-system.dll smaller.

First way is to use <cstdio> instead of <iostream>

Second way is 'Strip all symbols from binary'. (Are there any disadvantages, if you use this?)

Original: 499.78 KB

New sizes:
With cstdio: 33.83 KB
With cstdio and strip symbols:  14.00 KB

Compiled with MS VC: 12.50 KB

edit: But MSVC SFML-Window.dll is still  40 KB smaller than MinGW SFML-window.dll
edit2: And SFML-Network.dll is 270 KB (!!) smaller

[Boder]

You can try for "compile for size optimization" (and you can use UPX on your executable, compiling SFML statically).

But not much worry in these days of Gigabyte+ demos!

[workmad3]

I think mingw only has a static-linked runtime library, so you will be linking items of that into the dlls increasing size.

As for the options mentioned:
#include <cstdio>
makes sense if nothing in <iostream> is used <iostream> usually builds on <cstdio> so they would both be included, increasing code-size.

Stripping symbols - good idea but only for release mode (and true release mode at that, not a 'release' where you are still debugging but are linking against the release libraries). The symbols are what debuggers etc. use to give better info about where a crash occured.