Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Stack corruption with static linkage  (Read 1680 times)

0 Members and 1 Guest are viewing this topic.

Khatharr

  • Newbie
  • *
  • Posts: 11
    • View Profile
Stack corruption with static linkage
« on: April 06, 2015, 03:41:58 pm »
Hello.

I'm trying to get SFML 2.2 to link statically in VS2013.

I'm building in debug mode targeting x86.

I'm linking to the following libraries:
SFML:
sfml-main-d
sfml-system-s-d
sfml-network-s-d
sfml-audio-s-d
sfml-window-s-d
sfml-graphics-s-d

Misc Deps:
openal32
sndfile
freetype
glew
jpeg

OS:
ws2_32
opengl32
winmm
gdi32

I've done this with the binaries provided in the SFML 2.2 release and also with binaries I built locally by following the cmake tutorial.

I'm compiling and running the following code:
(click to show/hide)

When I run the project in the debugger, as I close it I get a notification from VS that the stack around 'window' is corrupted. Do I need to link different versions of the dependencies or is there some other problem that I'm missing here?
« Last Edit: April 06, 2015, 03:43:36 pm by Khatharr »

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Stack corruption with static linkage
« Reply #1 on: April 06, 2015, 04:15:10 pm »
It usually happens when you mix Release/Debug (or otherwise different configurations). When you built SFML yourself, have you paid attention to build exactly the same configuration, with same compiler version and settings?

Why is there <Windows.h> and a WinMain() function? Remove that and use a standard main(), the point of SFML is to avoid platform dependent code ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Khatharr

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Stack corruption with static linkage
« Reply #2 on: April 07, 2015, 01:47:07 am »
It usually happens when you mix Release/Debug (or otherwise different configurations). When you built SFML yourself, have you paid attention to build exactly the same configuration, with same compiler version and settings?

Yes, but since it's failing I suppose I can try starting the whole thing over from scratch in case I've changed a project setting somewhere along the line and forgotten about it.

Why is there <Windows.h> and a WinMain() function? Remove that and use a standard main(), the point of SFML is to avoid platform dependent code ;)

I appreciate that portability is one of the design goals of SFML, but from a usage standpoint that's not the feature I'm interested in for this project. Using the SFML main would obfuscate the arguments to WinMain(), which I may want to use at a later point.

Edit:
How infuriating. I replicated the project starting from scratch and it works correctly.

I made a specific point of not fiddling with the project properties, but apparently something was changed or else just went insane on its own. Oh well.

Thanks for the response.

Issue resolved: PEBKAC
« Last Edit: April 07, 2015, 02:19:00 am by Khatharr »