SFML community forums
Help => General => Topic started by: Critkeeper on May 13, 2015, 10:30:43 am
-
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?
-
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.
-
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
-
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
-
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.
-
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.
-
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?
-
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.
-
Does it happen with a simple return 0 program such as:
int main()
{
return 0;
}
-
Yes.
-
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.
-
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.
-
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.
-
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.
-
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.