-
So I'm trying to convert a project of mine from vc++2008 to vs2012, and discovered that since there are no ready built version of SFML for it I would have to compile it myself from CMake.
Firstly I would just like to say that I have never used CMake and I apologize in advance since the solution will most likely be obvious to veterans of CMake.
I followed the tutorial at
http://sfml-dev.org/tutorials/2.0/compile-with-cmake.php (http://sfml-dev.org/tutorials/2.0/compile-with-cmake.php)
I built the static libraries, with Visual Studio 11(not x64!) chosen as my generator in CMake.
After linking everything correctly(I think) I attempted to compile. I got a few errors which I corrected.
However during linking I get LNK1112 error, with the output saying:
error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' C:\Users\Admin\Google Drive\C++ project\VS2012\New Game\sfml-system-s-d.lib(Time.obj)
So I was wondering how I should fix this. Did I set something wrong in the CMake options, or is something else the cause?
Some general info:
- I am using CMake 2.8.10
- I am using Visual Studio 2012 Express
- The project itself was win32 in my vc++2008 configuration
-
Are you 100% sure the built libs are built as 32bit?
The error means that the linker found x64 builds.
Btw if you port your project I'd suggest to start with a new and empty project. ;)
-
Are you 100% sure the built libs are built as 32bit?
The error means that the linker found x64 builds.
Btw if you port your project I'd suggest to start with a new and empty project. ;)
I am not 100% sure, but I think they should be. I selected visual studio 11 as my generator so that should make them 32 bit right? Is there any good way to check?
-
Welp, I made a new project and got it running.. partways.
Now, upon compiling the project I get this error(after linking and when the application has launched)
Unhandled exception at 0x771022B2 (ntdll.dll) in Small Eye Coming Through.exe: 0xC0000005: Access violation writing location 0x00000004.
It points me toward the function MutexImpl::Lock
Any clues of why that error is there?
-
Is it coming from the constructor of a global variable? (look at the call stack)
-
Is it coming from the constructor of a global variable? (look at the call stack)
> Small Eye Coming Through.exe!sf::priv::MutexImpl::lock() Line 52
Is the line which the arrow is pointing to in the call stack.
Was that what you meant?(Sorry, I'm not used to using the call stack)
-
Look at the window with the callstack in it, so you see exactly from where the error originated, i.e. somewhere from your code.
-
Look at the window with the callstack in it, so you see exactly from where the error originated, i.e. somewhere from your code.
Sorry if I seem stupid, but I am not sure from where it is called, since I never call Mutex explicitly.
From the call stack, the frames/lines above the call to muteximpl::lock is
ntdll.dll!_RtlEnterCriticalSection@4 ()
Small Eye Coming Through.exe!sf::priv::MutexImpl::lock() Line 52
Does that help? :/
-
Look below, not above :P
-
Oh ok, sorry.
Here are the 3 lines below:
Small Eye Coming Through.exe!sf::Mutex::lock() Line 57
Small Eye Coming Through.exe!sf::Lock::Lock(sf::Mutex & mutex={...}) Line 39
Small Eye Coming Through.exe!sf::GlResource::GlResource() Line 49
-
Yeah... would be cool if you could go further, until you reach a function from your own code. Or post the full stack, if will be simpler ;)
By the way, we're wasting our time trying to get more information, but what about my first suggestion? Do you have a global SFML variable? If so, that's the problem and the solution is simply to make it not global.
-
ntdll.dll!_RtlEnterCriticalSection@4 () Unknown
Small Eye Coming Through.exe!sf::priv::MutexImpl::lock() Line 52 C++
> Small Eye Coming Through.exe!sf::Mutex::lock() Line 57 C++
Small Eye Coming Through.exe!sf::Lock::Lock(sf::Mutex & mutex={...}) Line 39 C++
Small Eye Coming Through.exe!sf::GlResource::GlResource() Line 49 C++
Small Eye Coming Through.exe!sf::Texture::Texture() Line 66 C++
Small Eye Coming Through.exe!Level::Level() Line 24 C++
Small Eye Coming Through.exe!LevelManager::LevelManager() Line 314 C++
Small Eye Coming Through.exe!`dynamic initializer for 'LvlManager''() Line 59 C++
Small Eye Coming Through.exe!_initterm(void (void) * * pfbegin=0x0163b488, void (void) * * pfend=0x0163b850) Line 894 C
Small Eye Coming Through.exe!_cinit(int initFloatingPrecision=1) Line 290 C
Small Eye Coming Through.exe!__tmainCRTStartup() Line 227 C
Small Eye Coming Through.exe!mainCRTStartup() Line 164 C
kernel32.dll!@BaseThreadInitThunk@12 () Unknown
ntdll.dll!___RtlUserThreadStart@8 () Unknown
ntdll.dll!__RtlUserThreadStart@8 () Unknown
There is the entire call stack.
The first function which comes from my code is the Level one. It is a constructor.
-
That looks an awful lot like it's in the startup code that, among other things, initializes global variables before main is entered.
-
This is definitely it
`dynamic initializer for 'LvlManager''
So... wait, no, I'm not going to repeat myself a third time :P
-
I had a container class which had SFML objects in it, when I moved the initalizer into main it worked. Sorry for taking up your time.