Mystery of the executable size

[Krice]

Almost exactly ten years ago I released the last version of Brick Atelier (a pixel art program). I compiled it with C::B and the size of .exe back then was 232Kb. Now ten years later and about 10K more lines added to the project I'm trying to compile it again, but something is different. When I compiled without static linking the size of .exe is 282Kb (by the way, the old version was 32bit and this new one is 64bit). However it wont run, because it requires libgcc_s_seh-1.dll, libstdc++-6.dll and libwinpthread-1.dll. You can add first two dlls with -static-libgcc and -static-libstdc++ flags. However static linking was not needed in the old version and no dlls were needed either.

When you statically link with those the .exe size is now 1027Kb so considerably larger than before, even with 32 to 64 bit difference. And I'm still missing that thread library, which, if someone knows how to statically link it can give me some advice how to do it. I'm now wondering how the linking worked in the old version 10 years ago? It must have been statically linked by default, right? And why the size difference, because the program is more or less same, with new features sure, but it's not that different.

[nenin]

And I'm still missing that thread library, which, if someone knows how to statically link it can give me some advice how to do it.

You can try "-static", it should link all "standard" stuff statically.

[Krice]

-static results to error messages, I guess it's trying to statically link SDL2 library also, which seems to fail.

[nenin]

-static results to error messages, I guess it's trying to statically link SDL2 library also, which seems to fail.

It should not be like this. You can try explicitly add SDL2 .dll, not .a, to list of the required libraries and test like this.
In general I have observations that for the new gcc lib should have name like *.dll.a to link dll. However, gcc can link dll directly.

[ollydbg]

When you statically link with those the .exe size is now 1027Kb so considerably larger than before, even with 32 to 64 bit difference. And I'm still missing that thread library, which, if someone knows how to statically link it can give me some advice how to do it.

If I remember correctly, the libwinpthread-1.dll (thread library) is only allowed to be linked dynamically. I guess you are using mingw64 based gcc? maybe the gcc inside msys2/mingw64.

[nenin]

If I remember correctly, the libwinpthread-1.dll (thread library) is only allowed to be linked dynamically. I guess you are using mingw64 based gcc? maybe the gcc inside msys2/mingw64.

It is correct, but if standard libs are linked statically and project does not require pthreads libwinpthread-1.dll is not necessary and should not appears in dependencies.

[ollydbg]

If I remember correctly, the libwinpthread-1.dll (thread library) is only allowed to be linked dynamically. I guess you are using mingw64 based gcc? maybe the gcc inside msys2/mingw64.

It is correct, but if standard libs are linked statically and project does not require pthreads libwinpthread-1.dll is not necessary and should not appears in dependencies.

In my memory, I think lib winpthread is a hard dependency that you can't remove. You can ask mingw64 devs for further question. 

[stahta01]

In my memory, I think lib winpthread is a hard dependency that you can't remove. You can ask mingw64 devs for further question. 

It is a hard requirement when building GCC when several libs are built.

The OP might try the new MINGW GCC using non posix threads and see if the exe is smaller.

Edit: Add link https://winlibs.com/ See the ones with MCF threads

Tim S.

[nenin]

In my memory, I think lib winpthread is a hard dependency that you can't remove. You can ask mingw64 devs for further question. 

Standard libs are under authority of the GNU, not MinGW64-w. It is why winpthread appeared actually.
Now it looks like this (see attach)

[nenin]

The OP might try the new MINGW GCC using non posix threads and see if the exe is smaller.

exe size is not pumped by thread libs, actually they all are compact.  I suppose bloating  is the result of the implementation of the C++ std functionality.  Even with dynamic linking a lot of stuff is in-lined and generated a solid footprint.

[Krice]

I ended up compiling with MSVC which had its own issues, but the resulted .exe is 250Kb. I was a bit uncomfortable with GCC license problems, although I don't think they are after some obscure freeware software. MSVC build obviously requires .dll files, but I think the redistributable package is usually already installed anyways. I quite dislike the legal text of GCC or GPL license, because it's not easy to even understand what you can actually do.

[nenin]

I quite dislike the legal text of GCC or GPL license, because it's not easy to even understand what you can actually do.

You can try clang, which can be found in some versions of WinLibs. clang has different license, as far as I know. However situation with exe size/dll`s will be the same.