SFML community forums

Help => General => Topic started by: Cirrus Minor on December 23, 2014, 08:16:28 pm

Title: CodeBlocks and SFML2.2 issue
Post by: Cirrus Minor on December 23, 2014, 08:16:28 pm
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 !
Title: Re: CodeBlocks and SFML2.2 issue
Post by: Ixrec on December 23, 2014, 08:31:29 pm
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?
Title: Re: CodeBlocks and SFML2.2 issue
Post by: Cirrus Minor on December 23, 2014, 08:39:12 pm
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.
Title: Re: CodeBlocks and SFML2.2 issue
Post by: Ixrec on December 23, 2014, 08:41:37 pm
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.
Title: Re: CodeBlocks and SFML2.2 issue
Post by: victorlevasseur on December 23, 2014, 08:47:03 pm
Just copy these libs from your MinGW bin folder.  ;)
Title: Re: CodeBlocks and SFML2.2 issue
Post by: StormWingDelta on December 23, 2014, 09:17:17 pm
Just copy these libs from your MinGW bin folder.  ;)
It'd be saner to just link to them. :)
Title: Re: CodeBlocks and SFML2.2 issue
Post by: eXpl0it3r on December 23, 2014, 10:10:56 pm
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 (http://www.sfml-dev.org/tutorials/2.2/compile-with-cmake.php) 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.
Title: Re: CodeBlocks and SFML2.2 issue
Post by: Cirrus Minor on December 23, 2014, 10:40:34 pm
Thanks, I understand now, why I did not have this behavior with 2.1, and I understand what I can do.
Title: Re: CodeBlocks and SFML2.2 issue
Post by: ChronicRat on December 24, 2014, 07:50:51 am
Sorry for offtop, but why use non-msvc compilers under Windows? There are no problems to use msvc-compiler in C::B.
Title: Re: CodeBlocks and SFML2.2 issue
Post by: eXpl0it3r on December 24, 2014, 11:06:21 am
I use MinGW/GCC for the C++11 support, plus it's faster.
Title: Re: CodeBlocks and SFML2.2 issue
Post by: Ixrec on December 24, 2014, 11:44:38 am
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).
Title: Re: CodeBlocks and SFML2.2 issue
Post by: ChronicRat on December 24, 2014, 05:45:21 pm
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.