static sf::Font initialization crashes program in MinGW4.7.1

[GarrickW]

So I recently upgraded to MinGW 4.7.1 and, lo and behold, it broke my program.

The debugger suggests that the culprit is a static sf::Font object I initialize in my Interface class (from Interface.cpp):

sf::Font Interface::m_Font;

The debugger says:

#0 669815E2     sf::Font::Font() () (C:\Users\Guerric\Desktop\CREATI~1\GAME-D~1\sfml-graphics-2.dll:??)
#1 0040521E     __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) (C:\Users\Guerric\Desktop\Creative Works\Game - Digitesque Prison\Interface.cpp:11)
#2 00405272     _GLOBAL__sub_I__ZN9Interface5m_AppE() (C:\Users\Guerric\Desktop\Creative Works\Game - Digitesque Prison\Interface.cpp:263)
#3 0042719A     __do_global_ctors () (??:??)
#4 004010DC     __mingw_CRTStartup () (??:??)
#5 00401295     mainCRTStartup () (??:??)

Any ideas on what is going wrong here?

[Nexus]

Don't use static or global SFML objects, there may be conflicts with their initialization order. In general, it's a good idea to avoid static and global variables where possible, even if it requires some reflection about the design.

[GarrickW]

Okay, so I just spent a while refactoring my code to get rid of crashing static variables, but now something even stranger is happening.  When I try to initialize an sf::VideoMode in main(), for use in the sf::RenderWindow I declare on the next line, that initialization crashes the program.

This occurs even if I remove everything else from the program, so that my main.cpp file looks like this:

#include <SFML/Graphics.hpp>

int main()
{
    sf::VideoMode GameMode = sf::VideoMode(800, 600, 32);
    return 0;
}

My debugger has only this to say:

#0 691C4AF9     sf::VideoMode::VideoMode(unsigned int, unsigned int, unsigned int) () (C:\Users\Guerric\Desktop\CREATI~1\GAMEEN~1\sfml-window-2.dll:??)
#1 0042C3F7     main() (C:\Users\Guerric\Desktop\Creative Works\Game Engine - Anthill\main.cpp:27)

I'm stumped.  Is it possible that there are some issues with SFML 2.0 and the 4.7.1 version of MinGW?

[eXpl0it3r]

Are you using the right version of SFML? Which package did you download or did you build it yourself?
Did you make sure not to mix debug and release modes?

[GarrickW]

I am using the version of SFML 2.1 labelled GCC 4.7 TDM (SJLJ) - 32 bits, which I am linking to in my compiler settings.  I didn't build it from the source code.

I also tried with the older version I had, SFML 2.0 RC, but that didn't work either.

I don't appear to be mixing debug and release, if by that you mean having linked the libraries under only one of the options but building in the other option.

[eXpl0it3r]

And what compiler are you using?

I don't appear to be mixing debug and release, if by that you mean having linked the libraries under only one of the options but building in the other option.

You have to link the debug libraries (-d suffix) in debug mode and the release libraries (no suffix) in release mode.

[GarrickW]

Ah, of course, that's important - yes, I am linking the -d files in Debug and the other files in Release.

Also, the compiler I use is the one that comes standard with CodeBlocks 12.11 - MinGW 4.7.1.

Just for kicks I uninstalled Codeblocks, reinstalled it and set up my linkages again, and tried building the window example that comes bundled with SFML 2.1.  The result is the following error, apparently at link-time:

The procedure entry point __gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll.

I checked, and I do have libstdc++-6.dll in MinGW's bin folder; I also tried copying it into the project folder, to no avail.

When I upgraded to MinGW 4.7.1, the very first problem I had was that it was telling me that I was using an unrecognized command line option "-static-libstdc++", and after asking around I was told that I didn't need to manually link since MinGW 4.7.1 statically links libstdc++ by default.  Might that have something to do with it?

[GarrickW]

I also tried a brand new, non-SFML project, and it worked fine; afterwards I integrated the simple example found here, and got the same error about a procedure entry.

[eXpl0it3r]

The procedure entry point __gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll.

This means, that the compiler or rather the runtime library is not compatible, thus your SFML package doesn't seem to match your compiler.

But if you use the one that comes with Code::Blocks by default, that would be the TDM SJLJ 32bit GCC 4.7.1 one, which should perfectly match with the "GCC 4.7 TDM (SJLJ) - 32 bits" package.
So I have to ask again: Are you really, really, really sure, that you didn't install another compiler/using another one by accident? Or are you really sure you didn't by accident click that "64 bits" package?

When I upgraded to MinGW 4.7.1, the very first problem I had was that it was telling me that I was using an unrecognized command line option "-static-libstdc++", and after asking around I was told that I didn't need to manually link since MinGW 4.7.1 statically links libstdc++ by default.  Might that have something to do with it?

How did you upgrade?

Unfortunately Dragon, the guy behind the TDM builds, thought it was better to not follow the GCC standard and lets the compiler link statically against the runtime libs by default and if you want to link the libs shared you'll have to add "-shared-libstdc++" etc.
It's a rather breaking change for a lot of build tools, but it's not something one should assume from a GCC compiler.

Personally I'd suggest to upgrade to something recent, like a MinGW Builds GCC 4.8.1 32bits POSIX Threading SJLJ, which is compatible with my Nightly Builds.

[GarrickW]

I actually found a thread that suggested the error might be related to SJLJ/DW2 on StackOverflow, so I deleted my old SFML install (not remembering which it was) and was quite careful to download the TMD build, 32-bits, and not the DW2 build - still the same problem.

Also, I "upgraded" by uninstalling my old CodeBlocks install and then installing the new one which, according to the site, comes packaged with TDM-GCC (version 4.7.1, 32 bit).  It's possible something was leftover from a previous installation, but when I uninstalled CodeBlocks everything in the CodeBlocks folder, which was where MinGW was installed, was removed, and I checked my compiler settings and found that it was indeed pointing to CodeBlocks/MinGW/ for the compiler directory, so it shouldn't be grabbing anything else.

I will follow your suggestion and upgrade to the 4.8.1 version, and see if that helps.

[GarrickW]

I installed the compiler you linked to and set that as my compiler in CB's compiler settings, yet I still get the exact same error.  Perhaps there is some other way to set the compiler settings I am not aware of...

UPDATE: I also tried using your nightly build TDM 4.7.1 32-bit instead of the version from the main site, and I tried compiling with the CodeBlocks-standard 4.7.1 as well as the 4.8.1, in all combinations, but they all generate that error.  And just to be safe I deleted my SFML files and re-downloaded the GCC 4.7 TDM (SJLJ) - 32 bits version, again.  None of that changed anything.

Perhaps I will try installing on another PC tomorrow.

[eXpl0it3r]

Seems odd that it wouldn't work with the TDM compiler and the TDM package/Nightly Build.
If you use the other compiler, you of course have to download the matching SFML Nightly Build. Also make sure to rebuild your projects when changing settings on the compiler.

[GarrickW]

So I was browsing MinGW/bin and discovered that the folder contains both libgcc_s_sjlj-1 and libgcc_s_dw2-1 DLLs (the install straight from the CB website).  If I delete libgcc_s_dw2-1, the compiler tells me that the program can't start because libgcc_s_dw2-1 isn't on my computer. 

So clearly the compiler is in fact trying to compile according to DW2 rather than SJLJ, but I can't figure out why or how to change it.  This is the third time I install CodeBlocks and MinGW directly from the provided package today after wiping out the old install (I think), and that should be SJLJ, which is what TDM uses, right?

[eXpl0it3r]

The TDM SJLJ for some strange reason ships with both SJLJ and DW2 runtime libs (probably another awkward thing of Dragon), so that's not the issue. Personally I find it really bad that all the guys are fully TDM pro, without even really understanding that shipping a non-standard conforming compiler is being shipped as "official" compiler of C::B. I tried to fight it, but people didn't even try to understand my arguments.
Sure Dragon's argument are valid (as later discussed via PM), but that doesn't prevent them to use a different compiler. I guess Dragon is just too closely coupled to the project.
In other news: TDM got an update to 4.8.1 1-2days ago.

Sooooo back to topic form my little rant.
Well in theory you can get whatever compiler you want, you'll just have to recompile SFML with that compiler. But if you don't want to do that, you'll need a matching package. I've 7 different MinGW versions lying around and for 6 of those I build SFML packages, which work without any issues on my end.
So something must be going wrong somewhere along the lines...

[GarrickW]

Well, I am definitely up for building SFML from the source if that solves my issues.  I've downloaded the source already; I suppose I'll read this and see what I can make of it.  I'll post again when I do and say whether I've had any luck.

Also, I hadn't been removing my CodeBlocks settings from AppData/Roaming previously, but doing so after uninstalling it doesn't seem to help either.