Re: [boost] Boost 1.29.0 recursive_mutex With gcc On Linux

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
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