Hi Björn, Mingw is a bit of niche platform for the OSG community so I'm afraid it doesn't get tested too often, those who do use it need to pitch in with reporting problems like you have and then working with us to resolve them.
Clearly the errors you have picked out need to be resolved by the build selecting on or other of the atomic lock implementations. I'm a unix only guy so have to defer to Windows users to recommend the best solution for under Windows. My own instinct would be to select the gcc path when compiling with gcc under Mingw, but without stepping through code very carefully won't be able to guess what modifications will be best. I don't have Windows let alone Mingw so can't test any modifications personally. Hopefully others can pitch in, but if they don't It'll be down to yourself to work out a viable solution. If you come up with something then posting it to osg-submissions would be appropriate. If you don't feel it's ready for inclusion and needs more general discussion then posting to this thread for others to comment/test would be appropriate. Cheers, Robert. Robert. On 20 July 2014 12:17, Björn Blissing <[email protected]> wrote: > Hi Robert et al, > > I tried to compile OSG with QT Creator using MinGW and GCC 4.8.2. > > It worked pretty well. But I found a case of ambiguous defines in > Atomic.cpp in OpenThreads. > > The problem is that both: > _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS > and > _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED > > is defined. This gives the following problems. > > 1. Since _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED is defined we will > enter the section: > > Code: > #if defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED) > #include <windows.h> > #include <intrin.h> > #pragma intrinsic(_InterlockedAnd) > #pragma intrinsic(_InterlockedOr) > #pragma intrinsic(_InterlockedXor) > #endif > > > > Which will result in warnings since intrinsic in an unknown pragma for > GCC. But since _InterlockedAnd, _InterlockedOr and _InterlockedXor ARE > defined inside intrin.h on MinGW it will work. So the pragma lines should > only be run if we are using MSVC. > > 2. But in the atomic operators we will not be able to use the previously > defined intrinsics, due to the fact that > _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS is defined. The compiler will never > reach the code inside _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED. > Example: > > Code: > unsigned > Atomic::operator++() > { > #if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS) > return __sync_add_and_fetch(&_value, 1); > #elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED) > return InterlockedIncrement(&_value); > #elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC) > return OSAtomicIncrement32(&_value); > #else > # error This implementation should happen inline in the include file > #endif > } > > > > I do not know if there are any benefits of using one or the other. But I > do not think we should define both. > > Best regards, > Björn > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=60356#60356 > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
