Thanks. I've sent an email to Blasius (hoping I got the email from Gmane correctly), and will see if he has a suggestion.
andy -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris Hi Andy, I don't have a Sun box or up to date knowledge to be about to suggestion resolution of this problem, save for reverting the addition of this code. The code was part of the submission below from Blasius Czink, perhaps we just remove the elements that are problematic - the OSG itself doesn't use the "and", "or" and "xor" features. Robert. -- r9059 | robert | 2008-10-27 10:42:58 +0000 (Mon, 27 Oct 2008) | 37 lines >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. " _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
