From: John Maddock (jm_at_[hidden])
Date: 2002-12-19 06:48:48
> 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
> 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
> 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
> in libpthread (from glibc-devel-2.2.5-40).
> The correct mutex attribute, PTHREAD_MUTEXATTR_RECURSIVE, is
> in /usr/include/pthread.h via the __USE_UNIX98 macro, which is set, in
> 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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk