hpux. I have skipped irix this time as irix is too dead to keep osg building
there.
As usual, solaris does not like member templates in stl containers.
Some headers missing and link problems due to missing libraries."
"changed the CmakeFiles for OpenThreads and the
osg-frameworks, so they are versioned by OPENSCENEGRAPH_SOVERSION. "
And from a later email:
"Attached you'll find a fixed version of ModulInstall.cmake. Hopefully it
works for old CMake-versions. I removed the offending line, and the
compile went fine on my end."
IF(!OSG_COMPILE_FRAMEWORKS) ...
vs.
IF(NOT OSG_COMPILE_FRAMEWORKS) ...
This has the effect of always compiling OpenThreads as a framework under OSX. The CMakeLists.txt that I use to be able to compile the non-framework version of OpenThreads is attached. I simply replaced the '!' replaced by a 'NOT' and added a MESSAGE to notify me when the .framework will be compiled."
- compile errors on windows when compiled with UNICODE flag
- warnings for duplicate WIN32_LEAN_AND_MEAN. I think this should
better fixed by adding WIN32_LEAN_AND_MEAN to vcproj preprocessor
list."
Mathieu Marache, he added the last missing piece to this puzzle.
I think it is safe to commit these changes to trunk, as the traditional
way via dylibs should work as before.
Here's some more info how to get frameworks:
With these modifications it is possible to compile frameworks on OS X,
when you set the Cmake-option OSG_COMPILE_FRAMEWORKS to true. If you
want to embed the frameworks in your app-bundle make sure to set
OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR accordingly.
You'll have to build the install-target of the generated xcode-projects
as this sets the install_name_dirs of the frameworks and plugins."
only create 376, then the program would hang.
376 * 8MB stack per thread = 3008 MB
The stack size allocated per thread blew the process address stack.
To get more threads you have to specify a smaller per thread stack,
but while the Thread::start says it will limit the stack size to the
smallest allowable stack size, it won't let it be smaller than the
default. I included the limits.h header to use PTHREAD_STACK_MIN as
the minimum stack size.
As for the deadlock, if the pthread_create failed, the new thread
doesn't exist and doesn't call threadStartedBlock.release(), so the
existing thread deadlocks on threadStartedBlock.block(). Only block
if the thread was started."
while in an else clause. When if is true the phase changes and the
while condition will always by false, so might as well put the while
in the else to skip the check. There's also a benefit to having the
code logic similar between platforms.
"
Barrier operations. The error is with atomic operations in the
win32 condition implementation. The attached sample program will
reliably trigger with as few as three threads and a dual core system,
though sometimes it will take 65,000 iterations.
2.8.1 was the base for these changes
Win32ConditionPrivateData.h
Win32ConditionPrivateData::wait does two operations to decrement
waiters_ then read, when InterlockedDecrement decrements and returns
the value in one operation. The two operations allows another thread
to also decrement with both getting 0 for an answer.
Win32ConditionPrivateData::broadcast is using waiters_ directly
instead of using the w value read earlier, if it was safe to use
waiters_ directly there would be no need for InterlockedGet or w.
overview of deadlock in barrier with three threads
one thread in broadcast, 2 threads in wait,
release semaphore 2, waits on waiters_done_
both threads wake, decrement waiters_, get 0 for w,
<logic error here>
one calls set waiters_done_,
broadcast thread comes out of waiters_done_,
other thread calls waiters_done_, (which leaves waiters_done_ in the
signaled state)
<sets the trap>
broadcast thread returns releases mutex, other threads get
mutex and also return,
next barrier, first two threads enter wait, one goes to broadcast, release
semaphore 2, skips waiters_done_ as it had been released last time
returns, processes, enters the barrier for the next barrier operation
and waits,
three threads are now in wait, two have the previous barrier phase,
one the current phase, there's one count left in the semaphore which a
thread gets, returns, enters the barrier as a waiter, sleeps, and the
deadlock is completed"
_beginthreadex() fails but OpenThreads still waits on the startup
Block before returning to the caller of OpenThreads::Thread::start().
This causes a deadlock. The return value of _beginthreadex() is
actually checked, but after the call to OpenThreads::Block::block() so
it is basically useless.
Attached is a fix to move the check for the return value of
_beginthreadex() before the call to block(), so that start() can
return to the caller with a non-zero error code. This solves the
problem for me."
order, and not in the order they are listed in the constructor. To
avoid possible trouble, gcc warns about this. Attached modification
fixes the initializer order to silence this warning."
Also, there was also a small bug in osgDB's CMakeLists.txt that was causing an error when I tested with CMake 2.4.4.
IF(${OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX} STREQUAL "quicktime")
was changed to
IF(OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX STREQUAL "quicktime")
"
openscenegraph.pc and openthreads.pc files with OSG's installation values.
Then I install those files into the expected path for pkg-config (this can
also be modified through PKG_CONFIG_PATH environment variable). Therefore
those of us who are using pkg-config for linking can easily select which
version of OSG we want to use."
working with that thing.
This is what was missing so far:
Make win32 threads behave like the posix implementation when setting thread
cpu affinity. That includes avoid setting thread affininty on a non running
thread. Set that once it is running."
On OpenThreads win32 implementation we unconditionally unlock a mutex in the
destructor. That happens even if the mutex was not locked before.
When running a osg application within microsofts application verifier, that
software checks tells me that we should not unlock an unlocked mutex.
When I look at the posix threads mutex implementation, which does no unlock in
the destructor and where it is illegal to destroy a locked mutex, I conclude
that it is not needed for an OpenThreads::Mutex to do that unlock in the
win32 Mutex destructor.
Thus this patch based on rev 9358 removes that additional unlock in the win32
mutex implementations destructor."
Updated all doxyfiles under doc/Doxyfiles. They are now all processed
by cmake but make targets are only generated for
OpenSceneGraphReferenceDocs and OpenThreadsReferenceDocs. The others
can be run with doxygen directly in <builddir>/doc.
Fixed a copy-paste in openthreads sproc and pthreads CMakeLists
Added the osg logo to the html footers
Added possibility to get generation of chm files.
CMakeLists (toplevel):
Added install of osg and ot reference docs. This also generates
packaging targets of openscenegraph-doc and openthreads-doc if you
have packaging enabled
Removed the unused USING_OP_OT_TRIPLE_SET since there was no way of
enabling it anyway
Removed BUILD_REF_DOCS. IMO it was redundant - BUILD_DOCUMENTATION
does the same thing and we get that anyway from including
Documentation.cmake.
OsgCPack.cmake:
Removed generation of PACKAGE_SRC for msvc
Added special handling for -doc packaging targets - they don't require
system, architecture or compiler"
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
"
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.
"
implementation of the atomic increment and decrement into a implementation
file.
This way inlining and compiler optimization can no longer happen for these
implementations, but it fixes compilation on win32 msvc targets. I expect
that this is still faster than with with mutexes.
Also the i386 gcc target gets atomic operations with this patch. By using an
implementation file we can guarantee that we have the right compiler flags
available."
