> continuing on with the "Deadlocking problems with recursive_mutex on Linux > with boost 1.29.0" thread, started by Beat Schaer on the 4th of this month; > I've come across the same issue on RedHat Linux 7.3 using gcc 2.96 but not > using gcc 3.0.4. > > The main point of the issue seems to be a hang over from a previous version > of Linux Threads where invoking pthread_mutexattr_setkind_np with > PTHREAD_MUTEXATTR_RECURSIVE_NP was the only way to set a recursive mutex. > > In /usr/include/pthread.h PTHREAD_MUTEXATTR_RECURSIVE_NP is still defined > but pthread_mutexattr_setkind_np is not and is only defined as a weak symbol > in libpthread (from glibc-devel-2.2.5-40). > > The correct mutex attribute, PTHREAD_MUTEXATTR_RECURSIVE, is conditionalised > in /usr/include/pthread.h via the __USE_UNIX98 macro, which is set, in turn, > if _XOPEN_SOURCE is defined and has a value >= 500, when > /usr/include/features.h is defined and which is not present in a default > invocation of gcc, but is present and defined in gcc3. > > Ideally, the workaround for this should reside in > $BOOST_ROOT/config/platform/linux.hpp but due to /usr/include/features.h > being included prior to the platform header file, I've devised a work-around > for $BOOST_ROOT/config/compiler/gcc.hpp as follows.
I don't think that we can work around this by defining _XOPEN_SOURCE in the boost headers: it would imply that the boost headers would have to be included before any other header, or nasty things will happen :-( I guess we could check for the _XOPEN_SOURCE value in posix_features.hpp as well as for _XOPEN_VERSION, maybe this is the right thing to do for all Unixes, I don't know, anyone any ideas? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost