Commit Graph

5 Commits

Author SHA1 Message Date
Robert Osfield
a64b412885 Reverted the usage of OSG_UNUSED and OT_UNUSED as in hindsight these should never have been merged. Adding code to quieten
inappropriate warnings is a bad programming practice and does not desrve a place in the OSG code base.
2013-07-01 08:21:13 +00:00
Robert Osfield
097aedf23c From David Callu, warning fixes and removal of spaces at end of lines. 2013-06-28 12:00:43 +00:00
Robert Osfield
14a563dc9f Ran script to remove trailing spaces and tabs 2012-03-21 17:36:20 +00:00
Robert Osfield
d703c58936 From Blasius Czink, "Among other things I added support for atomic operations on BSD-like systems and additional methods (for "and", "or", "xor").
"

and a later post the same osg-submissions thread:

"it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds."

And another post from Blasius on this topic:

"I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.

In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))

should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b))

The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I attached a corrected version.



    Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere.

OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that.
"
2008-10-27 10:42:58 +00:00
Robert Osfield
323ce02f23 Moved OpenThreads directly into OpenSceneGraph/trunk rather than being introduced via svn:externals.
This change has been done to make it easier for OpenSceneGraph users to check out the svn via https 
without any conflicts introduced with a http externals.
2008-04-01 10:49:53 +00:00