Ogre Forums

Posted: **Sat Jul 13, 2013 6:26 pm**

As the title suggests, this took me a lot of time to hunt and I'm not totally sure what solution to do as I lack knowledge about the history.

Here is the short version. In the following conditions:

- get TBB sources, then convert the VS project file to VS2012 project file (can be automated);
- get Ogre from source;
- set TBB as threading provider for Ogre;
- add some CMake code to make Ogre link with tbb (I can provide the code it's nothing special);
- generate VS2012 U3 32 bit version of the Ogre projects;

Then on compilation I get this error:

Code: Select all

1>e:\projects\games\netrush\netrush_dependencies\ogre\ogremain\include\OgreAtomicScalar.h(206): error C3861: 'InterlockedIncrement64': identifier not found
1>          e:\projects\games\netrush\netrush_dependencies\ogre\ogremain\include\OgreAtomicScalar.h(200) : while compiling class template member function 'unsigned int Ogre::AtomicScalar<T>::operator ++(void)'
1>          with
1>          [
1>              T=unsigned int
1>          ]
1>          e:\projects\games\netrush\netrush_dependencies\ogre\ogremain\include\OgreSharedPtr.h(105) : see reference to function template instantiation 'unsigned int Ogre::AtomicScalar<T>::operator ++(void)' being compiled
1>          with
1>          [
1>              T=unsigned int
1>          ]
1>          e:\projects\games\netrush\netrush_dependencies\ogre\ogremain\include\OgreSharedPtr.h(59) : see reference to class template instantiation 'Ogre::AtomicScalar<T>' being compiled
1>          with
1>          [
1>              T=unsigned int
1>          ]

After a lot of hunting why InterlockedIncrement64() wasn't defined, I finally found that it's because of this line in ConfigureBuild.cmake :

Code: Select all

if (OGRE_CONFIG_THREAD_PROVIDER STREQUAL "tbb")
		set(OGRE_THREAD_PROVIDER 3)
		include_directories(${TBB_INCLUDE_DIRS})
		if (WIN32)
			add_definitions(-D_WIN32_WINNT=0x0501)    # HERE
		endif ()

		set(OGRE_THREAD_LIBRARIES ${TBB_LIBRARIES})
	endif ()

This set the windows header (in our case, WinBase.h containing the problematic function) to provide only Windows XP BEFORE SP1 functions.
In this case, if the compiler is set to compile for 32bits, the macros hides 64 bits functions.
Apparently this flag is often used (in Ogre cmake files and it's dependencies) mostly for compatibility with MINGW, but in this specific line it is not the case.

So, why? It looks like the change is a recent patch by masterfalcon ( 409379704eea ) Which says: "Patch #1430 Fixed GL render system build for TBB".
The problem is that apparently this is not necessary at least in my build (which uses GL render system).

My immediate solution would be just to remove this line. However I suspect (but don't have the time to check right now) that
the binaries provided by Intel might have been compiled with MINGW which would explain this patch.
If I'm correct, I have no idea how to provide a patch to fix this because I don't see a way to know if the flag is necessary or not.

Thoughts?

Posted: **Sat Jul 13, 2013 7:52 pm**

Interesting. We'll need someone to see if that is the case. Perhaps we only need to define it if building with MinGW?

Posted: **Mon Jul 15, 2013 8:57 am**

I just checked:

- contrary to what I thought, the TBB binary distribution is all different visual studio builds, not mingw, beginning with vc9;
- the TBB project files in the source distribution don't need _WIN32_WINNT=0x0501 to compile (it's not defined in the projects command line);
- changing the pointed line to the following seems to work for me:

Code: Select all

                if (WIN32 AND MINGW)
			add_definitions(-D_WIN32_WINNT=0x0501)    
		endif ()

The only test I can't test myself is try to compile Ogre with MINGW + TBB.

Posted: **Sun Jul 21, 2013 8:30 am**

I've never compiled with TBB but I can give it a try with the line

Problem: I cannot get Ogre to find TBB.
TBB must have the weirdest build system ever... there is not even an "install" target and the tbbvars.bat which is supposed to setup correct ENV paths doesn't work.
But CMake keeps telling me that tbb could not be located, despite me setting the TBB_HOME, etc. variables in PATH.
Unfortunately, I really only have very limited time atm so I can't proceed here, sorry

However, I do know that DirectX, for example, really does require that _WIN32_WINNT 0x0501 for a number of other dfines and code includes to work correctly, so this solution could work.
But we'd need someone with MinGW who can get TBB to run properly to really test it.

Posted: **Sun Jul 21, 2013 11:51 am**

TheSHEEEP wrote:I've never compiled with TBB but I can give it a try with the line

Problem: I cannot get Ogre to find TBB.

Haha I see. I had a hard time making Ogre finding it too.
However it works now.

First thing to know is that there was a bug in the CMake script for 1.8.x that have been fixed in the last months,
so you need a recent 1.9 version, I'm not even sure the RC is enough. I waited that before trying to fix the problem.

Then the missing part is different as I'm building both tbb and Ogre from CMake...

TBB must have the weirdest build system ever... there is not even an "install" target and the tbbvars.bat which is supposed to setup correct ENV paths doesn't work.
But CMake keeps telling me that tbb could not be located, despite me setting the TBB_HOME, etc. variables in PATH.
Unfortunately, I really only have very limited time atm so I can't proceed here, sorry

I can provide my own CMake if you want? That could help decipher how I made it work.

However, I do know that DirectX, for example, really does require that _WIN32_WINNT 0x0501 for a number of other dfines and code includes to work correctly, so this solution could work.
But we'd need someone with MinGW who can get TBB to run properly to really test it.

Yeah sorry I don't use MinGW.

Posted: **Sun Jul 21, 2013 12:03 pm**

I just checked my history. I cheated to make tbb work! If I remember correctly, I read how FindTBB works in Ogre (because it's not the same than the official CMake FindTBB module that might work better....strike that I checked and there is no official one!) and I figured that some things were wrong, so before setting up Ogre I force things like this:

Code: Select all


set( TBB_ROOT ${CMAKE_CURRENT_0SOURCE_DIR}/itbb )
set( TBB_INCLUDE_DIRS ${TBB_ROOT}/include )
set( TBB_INCLUDE_DIRS ${TBB_INCLUDE_DIRS} PARENT_SCOPE )

set( TBB_FOUND TRUE ) # HERE

Note: TBB Don't use CMake yet (I'll provide CMake files to the TBB team soon as said there: http://software.intel.com/en-us/forums/topic/290889 )

So basically, just to be sure, I set TBB_FOUND to True before Ogre CMake files are parsed. If you have the right directories setup first, it
works perfectly for me now.

It's a hack but it works. It imply that the FindTBB module in Ogre is certainly wrong, but in the same time frankly the TBB source distribution is perfectly shitty and the directories in the binary distribution are complex for nothing indeed.
Hopefully they take participation for improving this.

Ogre Forums

Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS

Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS

Re: Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS

Re: Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS

Re: Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS

Re: Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS

Re: Ogre 1.9 Atomics + TBB 4.x from sources + 32Bits = FAILS