Boost logo

Boost :

From: Christoph Ludwig (cludwig_at_[hidden])
Date: 2004-06-30 09:54:24

On Wed, Jun 30, 2004 at 09:25:56AM -0400, David Abrahams wrote:
> Christoph Ludwig <cludwig_at_[hidden]> writes:
> >> BTW, I was told that if boost/config.hpp is included before any system
> >> headers, it will still be able to use _REENTRANT to detect if -pthread was
> >> specified on the command line.
> >
> > That's correct AFAICT, but does not really help. There's already too
> > much code that includes system headers before any boost headers.
> If we're in the same situation as Python, which requires "python.h" be
> included before any system headers, it's a damn shame. I don't
> understand all the reasons for this situation -- is it POSIX's fault?

The first problem is that the gcc option `-pthread' isn't documented
for linux / x86. If you search then
"pthread" is found only among the RS/6000 and PowerPC options. It's
therefore always some guesswork what you can expect from gcc if you
compile with pthread support. In particular, it's not documented how
you can *detect* pthread support.

IIUC POSIX does not (implicitly or explicitly) require any special
compiler flags when you compile C code that uses a pthread
implementation. I am not even sure whether it is strictly necessary to
use the `-pthread' flag if you compile and link such code with gcc or
whether it it is mainly a convenience option. (The situation may be
different for C++ code if, e.g., the EH code is affected by the
pthread support. But POSIX ignores C++, doesn't it?)

If I am correct then POSIX cannot require any means to detect
*activated* pthread support. I rather think it is a QoI defect of
gcc 3.4.

> Can we get them to fix this?

If you look at the discussion of gcc PR#11953
( then it seems the
gcc developers intend to restore the situation we had up to
gcc 3.3.x where you could rely on _REENTRANT. That won't happen before
gcc 3.4.2, though.



Boost list run by bdawes at, gregod at, cpdaniel at, john at