> > 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?
>
>
http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html#t
ag_02_02_01_01
>
>
On Thursday 19 December 2002 03:48 am, John Maddock wrote:
> 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 befor
[EMAIL PROTECTED] writes:
>> 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_SO
> 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.h
> 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 ha
