CodeBlocks and SFML2.2 issue

[Cirrus Minor]

Hi,
I've updated my project to SFML2.2.

My IDE is CodeBlocks 13.12 with GCC 4.7.1 under Windows.
I've installed GCC 4.7.1 TDM (SJLJ) - 32-bit version of SFML.

It's working (I mean I can compile, link and execute) but I now need libgcc_s_sjlj-1.dll and libstdc++-6.dll.

Does anyone why I need them now although I didn't with SFML 2.1 ?
And what can I do to avoid that ?
Thanks !

[Ixrec]

Those look like libraries for implementing the C++ language itself.  Are you sure this is an SFML thing and not a GCC/TDM/MinGW thing?

[Cirrus Minor]

Well, I've tried to compile and link again with SFML2.1 and I don't need the DLLs in this case.
I don't know if it's "because of" SFML2.2, but it's the only I've changed.

[Ixrec]

Are you statically linking?  The only linking thing I know of that changed for 2.2 is that static linking now requires linking all the dependencies yourself, instead of the magic hacks they were using before.  Maybe the magic hacks were getting these dlls before somehow.

[victorlevasseur]

Just copy these libs from your MinGW bin folder. 

[StormWingDelta]

Just copy these libs from your MinGW bin folder. 

It'd be saner to just link to them.

[eXpl0it3r]

The issue is: SFML 2.1 and older were built wrong for the TDM compilers - yes this is yet another TDM is stupid story.
TDM compilers link the runtime libraries (i.e. libgcc & libstdc++) statically by default, as opposed to any other GCC-like compiler. Previously SFML didn't account for that and thus even if you left SFML_USE_STATIC_STD_LIBS unchecked the runtime libraries were linked statically. This unintended behavior was fixed and the result is, that you'll need the runtime libraries if you leave the option unchecked. The SDK packages on the download page, have been built without SFML_USE_STATIC_STD_LIBS.

If you want them to be linked statically, you'll have to build SFML statically and check that box.

If you don't want to link statically, you need to add -shared-libstdc++ and -shared-libgcc to your linker flags and copy over the DLLs from your compiler binary directory.

[Cirrus Minor]

Thanks, I understand now, why I did not have this behavior with 2.1, and I understand what I can do.

[ChronicRat]

Sorry for offtop, but why use non-msvc compilers under Windows? There are no problems to use msvc-compiler in C::B.

[eXpl0it3r]

I use MinGW/GCC for the C++11 support, plus it's faster.

[Ixrec]

Code::Blocks and GCC are also cross-platform.  With MSVC you still have to use something else on the other OSs, and using two different toolchains is a pain.

MSVC also has an odd habit of letting you rely on Windows-specific functions or non-standard behavior without even realizing it (I'm basing that statement on my first port experience).

[ChronicRat]

I don't know about speed, but I have just two VERY BIG differences in my code between GCC and MSVC version: sprintf functions and this keyword for class fields in templates must be used for GCC but not required in MSVC. And I not use any additonal (runtime) DLLs - only static libs.