LNK 1112 compiling SFML 2.0 to VS2012

[natchos]

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
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

[eXpl0it3r]

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.

[natchos]

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?

[natchos]

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?

[Laurent]

Is it coming from the constructor of a global variable? (look at the call stack)

[natchos]

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)

[eXpl0it3r]

Look at the window with the callstack in it, so you see exactly from where the error originated, i.e. somewhere from your code.

[natchos]

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? :/

[Laurent]

Look below, not above

[natchos]

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

[Laurent]

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.

[natchos]

    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.

[cire]

That looks an awful lot like it's in the startup code that, among other things, initializes global variables before main is entered.

[Laurent]

This is definitely it

`dynamic initializer for 'LvlManager''

So... wait, no, I'm not going to repeat myself a third time

[natchos]

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.