linking issue : Undefined Reference to `_Unwind_Resume'

[paolo10]

Hi,
I wanted to get back to the SFML on my new computer. So I downloaded Code :: Blocks 16.01 with MinGW. I then downloaded this version of the SFML 2.3.2: "MinGW GCC 4.9.2 (DW2) - 32-bit."
Attached is a screenshot of what I get from the linker and an other of the result of gcc -v on the console (my OS is Windows 10).
Thank you in advance for your help

P.S : Sorry for my English, I'm French but i didn't get any result from the French forum :-/

[Gakinhos]

I might be wrong but I think that I just had this problem, two things that need to fix. First of all you need to download the GCC 4.8.1 TDM (SJLJ) - 32-bit version istead of the one you downloaded, if you do that and still have problems you should check if you got the right linking order in Compiler -> Settings -> Linker Settings, I will leave here a pic of how my order is.

http://prnt.sc/aw930r
http://prntscr.com/aw93af

[paolo10]

Thanks you very much !
I downloaded the version of SFML you advised me and it works !
i watched the screenshots you submitted but they seems too complicated you can only write :
sfml-graphics-s-d
sfml-window-s-d
sfml-system-s-d
mingw32
user32
gdi32
winmm
dxguid
opengl32
jpeg

Thanks again

[Jesper Juhl]

Another option that always works is to simply compile SFML yourself, using your chosen compiler. Then it's guaranteed to be compatible with the executables you produce.

[SuperApe]

(pls excuse bumping old thread again, but this matches close to a current issue)

Another option that always works is to simply compile SFML yourself, using your chosen compiler. Then it's guaranteed to be compatible with the executables you produce.

This totally makes sense, and it is why I downloaded source, configured cmake-gui to create a CodeBlocks project for SFML locally, and built "all" with all configurations I use (dynamic and static, debug and release).

After completing SFML build results, and moving the appropriate .dlls and .a files for use with my CodeBlocks project, I got the linker error described above - related to

libsfml-graphics-s.a(Sprite.cpp.obj):Sprite.cpp

So, thinking perhaps I'm working with the wrong compiler (MinGW as CodeBlocks 20.03 provides, instead of mingw32, as I had been using previously with CodeBlocks 17.02). After rebuilding SFML using the compiler directory CodeBlocks provides (MinGW - I see both SJLJ and DW2 there), and replacing the .a and .dlls, I got the same linker error.

Doing a bit more reading into this error, it seems just a .dll mismatch, but if I just built it, as Jesper says, shouldn't this just work? CodeBlocks does have settings to point to the correct compiler, and for 'auto-detecting' it. It does auto-configure to CodeBlocks' MinGW.

What would be a good next step here? This setup seemed a little more touchy, less smooth, with the new version of CodeBlocks install. (that's where the linking issues began)

Ideas?

(linker error results, pls excuse relative path to 32-bit install within CodeBlocks)

||=== Build: Release in AwesomeSecretProjectName (compiler: GNU GCC Compiler) ===|
..\..\..\..\..\..\Program Files (x86)\CodeBlocks\SFML-2.5.1\lib\libsfml-graphics-s.a(Sprite.cpp.obj):Sprite.cpp|| undefined reference to `_Unwind_Resume'|
..\..\..\..\..\..\Program Files (x86)\CodeBlocks\SFML-2.5.1\lib\libsfml-graphics-s.a(Sprite.cpp.obj):Sprite.cpp|| undefined reference to `_Unwind_Resume'|
..\..\..\..\..\..\Program Files (x86)\CodeBlocks\SFML-2.5.1\lib\libsfml-graphics-s.a(Sprite.cpp.obj):Sprite.cpp|| undefined reference to `_Unwind_Resume'|
||error: ld returned 1 exit status|
||=== Build failed: 4 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

[eXpl0it3r]

Yes for the new Code::Blocks version you need to build SFML yourself.

My suggestion is to delete every trace of any SFML library. Then build SFML from source with your current compiler and then use these new libraries to link in your application.
What I've seen often enough, is that people only remove some libraries or forget to change paths to the new location and then still work with the old version, wondering why it's not working.

When you google the error you'll find a lot of posts explaining that it's a compatibility issue between runtime versions. So if you truly build everything with the same compiler and don't somehow mixing in old runtime libraries or other libraries, you should be fine.