SFML community forums
Help => General => Topic started by: tokiwotomare on May 24, 2011, 12:15:11 am
-
So. My old development machine finally kicked the bucket. I'm on a new machine, a (somewhat) new environment, and trying to compile a program that worked just fine on the old machine on this new one.
The old machine was:
- Windows 7 basic (or whatever the very lowest version was)
- 32 bit
- Linking the static sfml2 libraries
- Using VS2010 express
- Worked like a champ!
The new machine is:
- Windows 7 ultimate
- 64 bit
- Linking the dynamic sfml2 libraries, which I re-compiled on this machine
- Still using VS2010 express
- Not working! :(
The program compiles just fine, but the second it starts, it crashes with the very helpful error message in the title.
Any ideas?
-
So. My old development machine finally kicked the bucket. I'm on a new machine, a (somewhat) new environment, and trying to compile a program that worked just fine on the old machine on this new one.
The old machine was:
- Windows 7 basic (or whatever the very lowest version was)
- 32 bit
- Linking the static sfml2 libraries
- Using VS2010 express
- Worked like a champ!
The new machine is:
- Windows 7 ultimate
- 64 bit
- Linking the dynamic sfml2 libraries, which I re-compiled on this machine
- Still using VS2010 express
- Not working! :(
The program compiles just fine, but the second it starts, it crashes with the very helpful error message in the title.
Any ideas?
Show me your code, although I do believe it's the 32-64 bit conversion that's screwing things up (since the error is in hex code)
Here's something I found: http://www.sevenforums.com/general-discussion/41098-application-unable-start-correctly.html
-
The code is ... quite large! Since I can't really narrow down the specific culprit, I can't really post it.
Someone in that thread suggested that his problem was a side-by-side with the .NET framework. Does SFML require a specific one? I didn't think it required .NET.
Edit: Another question -- are there pitfalls related to 64-bit that I should watch out for? I thought that if I just recompiled the current source on my 64-bit machine it should be fine.
-
Gah, I'd rather not go into details
I just googled your error message and came up with what looks like potential results :wink:
-
^^
Thanks for the effort anyway!
-
The code is ... quite large! Since I can't really narrow down the specific culprit, I can't really post it.
Really? If it's a configuration problem (and it most likely is) the code shouldn't matter. Do you mean that you get no error with simple codes (like the SFML examples)?
-
Good question -- I'll try a simple SFML example tonight and see if it runs.
What I meant was that I think it is indeed a configuration error, as the code doesn't even start to run (stepping into the debugger, for example, or setting a breakpoint on the entry of main).
-
Okay, so I tried the very simple Window example --
#include "stdafx.h"
#include <SFML/Window.hpp>
int main()
{
// Create the main window
sf::Window App(sf::VideoMode(800, 600, 32), "SFML Window");
// Start main loop
bool Running = true;
while (Running)
{
App.Display();
}
return EXIT_SUCCESS;
}
Linking only sfml-window-d.lib (which I re-compiled on this machine), and using SFML_DYNAMIC.
Still gives me the same error!
-
Could the application be compiling in 64bit while the sfml dll's are 32bit? Or the other way around? I believe that would screw things over pretty badly.
Try with forcing both your project and SFML to 32 bit and see if it works.
-
Just checked -- both are compiling in Win32 Debug mode.
-
Linking only sfml-window-d.lib (which I re-compiled on this machine), and using SFML_DYNAMIC.
Still gives me the same error!
Might be this, sfml-window depens on sfml-system so you have to link that one too.
-
It wouldn't compile if that were the case -- I suffered through setting up linking and all that the first time :)
-
So, some additional info -- it appears to be the actual linking that's causing the crash.
I took the simple tutorial example and tried building it without linking the library (and commenting out subsequent library calls). It ran!
However, linking the library (in this case, sfml-window-d.lib) causes this crash. Any ideas?
-
A bit more additional info:
- I switched over to my Ubuntu box, and, using all the same settings (what to link, dynamic vs static, etc), the only difference being the actual libraries compiled (64-bit Linux instead of Windows) ... it works just fine.
- I switched over to Code::Blocks on the Windows box, thinking that maybe VS2010 was doing something weird. Recompiled the libraries; linked everything the same way ... I get the same error. So it's not an IDE quirk; it's definitely something going wrong with Windows 7.
My best guess -- based on a lot of very general, "not sure what I'm looking for" Googling -- is that there's some mix-up going on between 32- and 64-bit, but ... I have no idea what, or where to even begin with that.
As far as I could tell, there aren't 64-bit-specific Windows libraries in the source.
Any ideas at all? I'll try anything at this point! I'm happy to develop on the Ubuntu box, but the added inconvenience is a pain :lol:
-
Sorry to bump an old thread. However, I was having a similar problem and I fixed by swapping from using the x64 libsndfile-1.dll to the x86 libsndfile-1.dll.
I am also on Windows 7 64bit. However, unless you have specifically configured VC++ Express to work with the 64bit toolset of the Windows SDK, you are bound to 32bit compilation anyway.
I assume I could use the 64bit one if I compiled a 64bit application?
-
I haven't tested 64 bit but from my understanding then yes you would be able to.