Is there any way to get code::blocks to work with gcc 4.9.2 minGW SFML package?

[Critkeeper]

I tried downloading the TDM-GCC 4.9 series minGW compiler and creating a new compiler option in the build settings for the project pointing to it, and I made sure to use the correct SFML package that was compiled using that compiler.

But I still get unwind errors indicating that there is a problem with how the stack is being used, and that is typically caused by the library being compiled with a different compiler or version than the source you are linking it with.

Does that mean TDM's implementation of minGW isn't compatible?

[shadowmouse]

Try this version of mingw http://sourceforge.net/projects/mingw-w64/
If I remember correctly that is the installer so you have to choose 4.9.2, the rest of the settings should be set up correctly. Then download the version of codeblocks without a compiler and build sfml with cmake.

[Critkeeper]

I tried what you provided and it links and compiles code that I know works without throwing any errors or anything.

I didn't download and build sfml, I just used to MinGW 4.9.2 package. And I didn't download the version of codeblocks that doesn't have any compilers, I just made a new compiler option. I don't see how any of that should matter if it syncs up anyway, but if it doesn't then please let me know.

I had to remember to set the toolchain up but I'm not certain I did it properly.

C compiler is set to
i686-w64-mingw32-gcc-4.9.2.exe

C++ compiler is
i686-w64-mingw32-g++.exe

Linker is
i686-w64-mingw32-g++.exe

Linker for static is
ar.exe

Debugger is
GDB/CDB debugger : Default

Resource compiler is
windres.exe

Make program is
mingw-32-make.exe

[Critkeeper]

I am getting a strange error when I try to run a hello world program with this set up.

It says

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

[shadowmouse]

According to this http://stackoverflow.com/questions/28221184/the-procedure-entry-point-zst24-throw-out-of-range-fmtpkcz-could-not-be-locate you're using the wrong version of the dlls.

[Critkeeper]

But I thought by linking static I could avoid using DLLS

These are my link libraries:

sfml-graphics-s-d
freetype
jpeg
sfml-windows-s-d
opengl32
gdi32
sfml-audio-s-d
FLAC
ogg
vorbis
vorbisenc
vorbisfile
openal32
sfml-network-s-d
ws2_32
sfml-system-s-d
winmm

I still include open OpenAL32.dll in the same folder as the executable but I keep getting that strange error.

Also, it doesn't matter if I change the programs used in the toolchain to:

C compiler is set to
gcc.exe

C++ compiler is
g++.exe

Linker is
g++.exe

Linker for static is
ar.exe

Debugger is
GDB/CDB debugger : Default

Resource compiler is
windres.exe

Make program is
mingw-32-make.exe

Since the thing compiles and links without errors, it can't be a compiler or a linker error. I must be linking to the wrong DLL like you said, but I can't figure out how or why.

[shadowmouse]

Have you defined SFML_STATIC? I don't know if that's the problem but  it's still trying to access a dll and if you correctly made it static it shouldn't access any dlls other than openal32. By the way, if it compiles correctly, when are you getting that error?

[Critkeeper]

I have SFML_STATIC defined in the compiler settings under global compiler settings along with the linker settings and search directories. And I am making sure that my selected compiler for the project is the same compiler I am defining these settings for.

I get the error once I try to run the program. It doesn't happen until I hit "run" and the console pops up, but happens before anything can be put to the console.

[shadowmouse]

Does it happen with a simple return 0 program such as:

Code: [Select]

int main()
{
    return 0;
}


[Critkeeper]

Yes.

[shadowmouse]

In that case I'm pretty sure it's a problem with your putting together of codeblocks and mingw but I'm going further and further into the realms of educated guesses here. As a final check, if you make a new project, try that code, then if it works, link sfml and try that code, then if that works, try the tutorial circleshape program.

[Critkeeper]

Both of those things work -_-

I am absolutely confused.

EDIT:

Wait nvm I chose the wrong compiler at project creation. After choosing the compiler option I made for MinGW 4.9.2, it crashes on a normal hello world program and on the return 0 program.

SECOND EDIT:

well...

.

.

.

You ever make the same mistake, but the opposite, twice in a row and look like a dumbass for it? Cause yeah. It works.

[shadowmouse]

If you've got an SFML project up and running now then the other one probably has some obscure mistake in it, but if you've got it working now, just use that one.

[Critkeeper]

Problem resolved guys!

When creating a new compiler option and defining its settings you can't be certain that simply changing the compiler of your project in code blocks will not cause a run time error.

To be safe, define the new compiler and set it up properly and then create a new project with that compiler selected at construction. Then it should work without a hitch. Unfortunately that can mean a lot of copy and pasting, or atleast moving files around. Oh well.

[eXpl0it3r]

My guess is that you didn't fully rebuild the project as the warning that pops up when changing the compiler is telling you to.