Static Link Errors

[wintertime]

I think recompiling SFML yourself would get it working faster for you. For example I compiled SFML with the TDM 4.5.2 compiler from the Ruby DevKit once, because I knew there is no way around it to get a compatible version if noone else provides it.
Finding the newest 1.6 compatible commit in git is a tiny bit of extra work though.

[eXpl0it3r]

Sorry, I forgot you're using SFML 1.6 (too many similar topics), but this is essentially your main issue. SFML 1.6 is very outdated and a conversion to 2.x takes a bit time, but is completely worth it!

This branch is 22 commits ahead and 1206 commits behind master

But since you've already made up your mind...

Back when SFML 1.6 was built, there weren't many options regarding MinGW, heck I think there wasn't even the MinGW-w64 project, thus it's essentially rather easy to find the matching compiler. You can try the installer, maybe it will let you download the old version as well, but you can also get the compiler itself here.

Well, I'm operating 1.6 and according to the forum pages I linked, 1.6 needs 4.4 (but I don't know if that's 4.4.0 or 4.4.1: I'm assuming 4.4.0). Alternately, it could be because I have a SJLJ version and not a DW2 version.

Looking at the MinGW directory, I would assume it's 4.4, but SJLJ and DW2 are not compatible as well.

I think a newer version of GCC will just make the problem worse.

Why would you think that? SFML 1.6 doesn't have the nice CMake build system, but it has a simple makefile and if you get MSYS as well, you can easily build it.

Finding the newest 1.6 compatible commit in git is a tiny bit of extra work though.

It has its separate branch.

[Joshua Flynn]

Looking at the MinGW directory, I would assume it's 4.4, but SJLJ and DW2 are not compatible as well.

The SJLJ and DW2 incompatibility is primarily the main problem here. But I can't determine how to determine what the compiler is using.

Why would you think that? SFML 1.6 doesn't have the nice CMake build system, but it has a simple makefile and if you get MSYS as well, you can easily build it.

Because 1.6, per Laurent's statement cited in the other post, was built on 4.4. So it's easier if I simply 'tack on' a 4.4 compiler that uses DW2 (per the specification also noted in Laurent's post in the other thread, linked to, other post) into Code::Blocks for the short duration of this task (which is simply getting an SFML program to work on a 64 bit machine and the 1.6 DLLs are 32 bit which means I have to static link the executable), rather than ripping and changing a massive amount of libraries only to break some fundamental code and require maybe months of debugging, and I have less than a week.

So, newer (appeal to novelty is a fallacy, by the way), is not better. If 4.4.0 does the job, then it does the job. Any newer version would probably introduce a new set of errors: we only want to solve the current problem, not upgrade the system. Upgrading the system offers benefits I don't actually need at this stage.

Finding the newest 1.6 compatible commit in git is a tiny bit of extra work though.

It has its separate branch.

I operate a custom 1.6 SFML build. So Mohammed must go to the mountain.

(Seems to be the solution is quite apparent: DW2 GCC 4.4.0 compiler. I don't see why I have to reinstall and alter an entire codebase just to avoid adding on 'one more' compiler to the many I have. I won't be replacing 4.4.1, just adding 4.4.0 to the list of options in Code::Blocks).


I won't make the jump to the newest SFML library until this laptop dies or goes bust: a lot of the codebase is built for windows on a custom (network tweaked) 1.6 SFML build, and I'm planning to 'jump' to Lubuntu, which will mean a lot of the codebase will be rendered void. So rather than change up now, I'm planning to 'jump' fully to Lubuntu, start up the newest SFML library and then go through the complicated setup and salvage process.


So, away from my design and configuration decisions: how do I tell which of these 4.4.0 compilers are windows compatible and use DW2?:
http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/Previous%20Release%20gcc-4.4.0/

[wintertime]

Now I think, if I remember correctly, they only provided SJLJ at that stage to avoid the issue of crashes on DW2 exceptions thrown from a callback through a dll back to your program.

Edit: I guess I found something for you to try: http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.905.0/ or http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Old%20Releases/TDM-GCC%204.4%20series/Previous%20Releases/4.4.0-tdm-1%20%28r2%29%20DW2/

[Joshua Flynn]

Now I think, if I remember correctly, they only provided SJLJ at that stage to avoid the issue of crashes on DW2 exceptions thrown from a callback through a dll back to your program.

Edit: I guess I found something for you to try: http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.905.0/ or http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Old%20Releases/TDM-GCC%204.4%20series/Previous%20Releases/4.4.0-tdm-1%20%28r2%29%20DW2/

Thank you, I'll give these a try.

[Joshua Flynn]

No dice, installed the TDM-GCC version supplied and added the DW2 parts, made sure compiler defaulted to the 4.4.0 version, still getting errors:

Code: [Select]


-------------- Build: Release in SelfBuilding ---------------

mingw32-g++.exe  -o "bin\Release\CV Project.exe" obj\Release\main.o  obj\Release\resources.res  -static-libgcc -static-libstdc++ -lsfml-audio-s -lsfml-network-s -lsfml-graphics-s -lsfml-window-s -lsfml-system-s -s  -lpthread -lcomdlg32 -lGdi32
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x135): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x1ad): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x21d): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x35a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x4a6): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0x6f2): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0x76a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0x998): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0xbc4): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0xcba): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.text+0xdb2): more undefined references to `_Unwind_Resume' follow
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Sound.o):Sound.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x2ee): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x35a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x3ce): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x43a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.text+0x49e): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundStream.o):SoundStream.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x19e): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x2ad): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x3aa): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x414): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x47c): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.text+0x4ee): more undefined references to `_Unwind_Resume' follow
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFile.o):SoundFile.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x3aa): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x476): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x569): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x675): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0x781): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.text+0xc61): more undefined references to `_Unwind_Resume' follow
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundBuffer.o):SoundBuffer.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioResource.o):AudioResource.cpp:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioDevice.o):AudioDevice.cpp:(.text+0x40a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioDevice.o):AudioDevice.cpp:(.text+0x461): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(AudioDevice.o):AudioDevice.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.text+0x136): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.text+0x17a): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.text+0x1c6): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileOgg.o):SoundFileOgg.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x2c2): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x306): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x352): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.text+0x859): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(SoundFileDefault.o):SoundFileDefault.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Listener.o):Listener.cpp:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-graphics-s.a(Sprite.o):Sprite.cpp:(.text+0x941): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-graphics-s.a(Sprite.o):Sprite.cpp:(.text+0x9fd): undefined reference to `_Unwind_Resume'
c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-graphics-s.a(Sprite.o):Sprite.cpp:(.text$_ZN2sf6SpriteD0Ev[sf::Sprite::~Sprite()]+0x15d): undefined reference to `_Unwind_Resume'
Process terminated with status 1 (0 minutes, 1 seconds)
50 errors, 0 warnings

So I'm stuck, unless someone can figure a way for me to solve the 64-bit problem by another means?

[eXpl0it3r]

The SJLJ and DW2 incompatibility is primarily the main problem here. But I can't determine how to determine what the compiler is using.

On Windows the smallest change in the version number of GCC makes binaries incompatible as of my experience, although one can always run into lucky cases (with possible time bombs).

Because 1.6, per Laurent's statement cited in the other post, was built on 4.4.

It was not built on GCC 4.4, but it was built with GCC 4.4. SFML doesn't use and has used code that would be "optimized" for a certain compiler. As long as the compiler has proper C++98 support SFML can be built (for now).
With that said, I won't further discuss that part of the topic, it's your decision alone.

I operate a custom 1.6 SFML build. So Mohammed must go to the mountain.

How can you run your own branch while using the official binaries?
If you use your own branch then you need to recompile anyways, so the discussion around what compiler to use is essentially useless since you can use which ever you currently have.

So, away from my design and configuration decisions: how do I tell which of these 4.4.0 compilers are windows compatible and use DW2?:
http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/Previous%20Release%20gcc-4.4.0/

I think you still haven't understood what MinGW is. It's first a way to use GCC for Windows, so if one talks about MinGW one mostly always talks about a Windows compiler, and second it's a cross-compiler on Linux, thus if someone actually is talking about something on Linux, then they are still trying to build for Windows.

If you had spent more than two seconds looking at the file list, you'd have noticed that there's only one compiler you're essentially have interest in, namely "c++". If you spent even a bit more, you might have seen the "full" package. So I went ahead and quickly tested it and it's a 4.4.0 compiler with DW2, as seen by calling gcc -v:

Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)

Full Package (contains compiler for ada, etc as well): Download
Minimal C++ Packages : c++ bin, c++ dll, core bin, core dll

[eXpl0it3r]

made sure compiler defaulted to the 4.4.0 version, still getting errors:

Code: [Select]

c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x135): undefined reference to `_Unwind_Resume'

Why does it still use the MinGW directory for 4.4.1? If you have this a path for the libs in your settings, you might want to change it, since it potentially can confuse the compiler even further when it has the same lib dir twice.

So I'm stuck, unless someone can figure a way for me to solve the 64-bit problem by another means?

64-bit problem?

[Joshua Flynn]

How can you run your own branch while using the official binaries?
If you use your own branch then you need to recompile anyways, so the discussion around what compiler to use is essentially useless since you can use which ever you currently have.

The network DLLs were all that I replaced (as that was the only part I was having problems with). But the rest are de facto downloads. But the problem seems to oddly crop up when sfml-audio is turned to -s: but I can't omit it as sound is a fundamental part of the program. I can omit networking (but it'd be nice if I could showcase networking as well).

The network DLLs were compiled with the same compiler, but aren't the problem.

I don't get why Dynamic Link Libraries and their compile process would have anything to do with statically linked libraries, which I assume just compile the code at run time and merge it with the source code?

I think you still haven't understood what MinGW is. It's first a way to use GCC for Windows, so if one talks about MinGW one mostly always talks about a Windows compiler, and second it's a cross-compiler on Linux, thus if someone actually is talking about something on Linux, then they are still trying to build for Windows.

But if you're talking windows compiler, doesn't "cross-compiler on Linux" nullify your point it's "for windows"?

If you had spent more than two seconds looking at the file list, you'd have noticed that there's only one compiler you're essentially have interest in, namely "c++". If you spent even a bit more, you might have seen the "full" package.

Rather than present a direct link to the singular and apparently only obvious file, you decided to present an entire list including unnecessary file references and then berate me when I get confused?

S stands for simple, y'know, not snarky.

[Joshua Flynn]

made sure compiler defaulted to the 4.4.0 version, still getting errors:

Code: [Select]

c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libsfml-audio-s.a(Music.o):Music.cpp:(.text+0x135): undefined reference to `_Unwind_Resume'

Why does it still use the MinGW directory for 4.4.1? If you have this a path for the libs in your settings, you might want to change it, since it potentially can confuse the compiler even further when it has the same lib dir twice.

That's where the SFML libraries are stored.

We've only changed the compiler, not the SFML libraries we're using. I don't see how duplicating the SFML files to the other compiler helps?

Also, it can't get confused: the two compilers reside in two completely different directories.

64-bit problem?

Okay, story in full:
I constructed an SFML program that works fine on my machine (32-bit, Vista), and works fine on another laptop (32-bit, Vista) showing the DOS-esque screen debug data and graphics window, but on a 64-bit (Vista) machine, shows only a static black DOS (it doesn't print any starting messages either, and doesn't report any errors or missing libraries).

If, however, I compile an .exe that DOESN'T use SFML and send it, the program runs fine and displays the message. If I use any kind of SFML code, it doesn't play ball (debug and normal libraries are both available, and it works on the other 32-bit laptop fine, note).

I know that 1.6 has 32 bit DLLs and no 64-bit ones. So my idea is to include the library as statically linked into the main program so it doesn't rely on the external 32-bit libraries and see if that works. Except that is quite obviously easier said than done.

[wintertime]

Static libraries are basically the same code as dynamic, the only difference is the linking is not postponed until loading. It wont solve an incompatibility.
A 64 bit OS can easily use 32 bit binaries, but if you use 32 bit dll files you need to compile your program in a compatible way, that means as 32bit with a compiler with a compatible ABI. The easiest way to do that is recompile both SFML and your program using the same compiler.
Then if its running on one computer, if you copy the exe and all dll files over to another and make sure it uses these dll files (put them into the same directory or double check the dll files are the only SFML dll files in path), it should work there too.

[Joshua Flynn]

Static libraries are basically the same code as dynamic, the only difference is the linking is not postponed until loading. It wont solve an incompatibility.
A 64 bit OS can easily use 32 bit binaries, but if you use 32 bit dll files you need to compile your program in a compatible way, that means as 32bit with a compiler with a compatible ABI. The easiest way to do that is recompile both SFML and your program using the same compiler.
Then if its running on one computer, if you copy the exe and all dll files over to another and make sure it uses these dll files (put them into the same directory or double check the dll files are the only SFML dll files in path), it should work there too.

What exactly am I looking to recompile SFML into and what files am I looking to copy where?

The 'Flynn Edition' (FE) version of SFML is compiled 'off-site' (stand alone directory) and the relevant DLLs are simply tacked in with the main program which conventionally is dynamically linked. This is obviously not the case with static linking because it's obviously trying to pull the code from somewhere. What files am I looking to transfer from the FE compile to the compiler's directory?

[eXpl0it3r]

Rather than present a direct link to the singular and apparently only obvious file, you decided to present an entire list including unnecessary file references and then berate me when I get confused?

S stands for simple, y'know, not snarky.

Well then, good luck.

[amir ramezani]

have you downloaded Code::blocks with a MinGW?
if yes, it use's SJLJ
so, you have to download SJLJ version of SFML, not DW2

MinGW is a port to GCC on windows
it is GCC that's compiled for windows
i recommend to upgrade to GCC 4.8
as it's more standard and SFML support's it
and another recommendation is upgrade SFML to version 2.x
as it has many bug fixes and many features than version 1.6

the difference between dynamic and static is:
when you compile your application with a dynamic library, it want to find a dll for it and load the functions from it
while you compile it with a static library, the functions are imported to the application and it does not require a file to be located to path directorys
i recommend you to visit
http://MinGW.org/
and download the latest MinGW and give it's path to Code::Blocks and copy all your libraries and include files and compile your game with it
please note that:
don't replace any library or an include file!
it may destroy the files
because they are incompatible with the previous versions of GCC

[Joshua Flynn]

Well, after all this madness about compiler changes, writing a load of code, installing stuff that would make the problem worse, there's a hacky solution that actually works:

Code: [Select]

int _Unwind_Resume;
int __gxx_personality_v0;

Append that to the top of the .cpp file allows it to compile because, basically, those two are merely undeclared variables that the system is searching for. THE ONLY TWO VARIABLES, EVER.

I am sure this is breaking something major on the most fundamental levels. but I have ONLY THREE DAYS to get this project done, and you don't throw me what amount to basically two undeclared variables and expect me to run around the houses to solve it.

GOGI