|
Boost : |
From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-10-05 11:31:26
On Tue, Oct 05, 2004 at 04:06:44PM +0100, John Maddock wrote:
> >When compiling the smart pointer tests with gcc 3.4.2 on Tru64, two tests
> >fail with an error message. (See http://tinyurl.com/4jngu )
> >
> >As far as I can see, the shared pointer implementation at some point
> >includes the "pthread.h" system header file but gcc on Tru64 requires
> >that -pthread must be specified on the command line when including this
> >header file.
> >
> >When running this test with gcc 3.4.2 on Linux the file "pthread.h" is
> >also included but gcc doesn't require the addition of -pthread in the
> >command line on this platform.
> >
> >This leads to the question whether it is ok to include "pthread.h" without
> >specifying -pthread on the command line. Does anyone know an answer to
> >this?
>
> I think on some platforms <pthread.h> doesn't compile unless _REENTRANT or
> some similar compiler-specific magic symbol is defined: in other words it's
> an assert that the compiler is indeed in thread safe mode.
IIUC "some platforms" applies to Tru64 and nothing else.
> It looks to me as though BOOST_HAS_THREADS is getting set unconditionally
> for gcc on this platform, and presumably we should only set it when
> _REENTRANT is defined
See GCC PR 11953 - _REENTRANT gets defined unconditionally for GCC 3.4 on
all platforms when configured to use pthreads, and therefore BOOST_HAS_THREADS
also gets defined unconditioanlly. That's what PR 11953 is about :)
GCC was changed to unconditionally define _REENTRANT precisely because
Tru64 requires it before including pthread.h (and libstdc++ wants to
include pthread.h). I might update the PR to say that this causes
problems even on Tru64, where it was supposed to help (although the
response will be to tell me again that Boost should never have used
_REENTRANT anyway)
> (I'm assuming that's the symbol that gets defined
> when the -thread option is used - can you check?).
Yes, assuming I'm looking at the right file, gcc/config/alpha/osf.h:
#undef CPP_SUBTARGET_SPEC
#define CPP_SUBTARGET_SPEC \
"%{pthread|threads:-D_REENTRANT} %{threads:-D_PTHREAD_USE_D4}"
/* Under OSF4, -p and -pg require -lprof1, and -lprof1 requires -lpdf. */
#define LIB_SPEC \
"%{p|pg:-lprof1%{pthread|threads:_r} -lpdf} %{a:-lprof2} \
%{threads: -lpthreads} %{pthread|threads: -lpthread -lmach -lexc} -lc"
> Hold on... checked the output from config_info and looks as though
> _REENTRANT *is* defined, so I'm mystified.
That's because the config_info test includes <iostream> which indirectly
defines _REENTRANT and includes pthread.h
Sooooooo .... why is the compiler saying Markus needs to define it if it
is defined? (sorry John, I see what you were getting at now :)
Markus, could you send me the pthread.h header from GCC?
That's the one that GCC produced by running fixincludes on the system
pthread.h:
/usr/opt/gcc-3.4.2/bin/../lib/gcc/alphaev56-dec-osf5.1/3.4.2/include/pthread.h
Or at least show what's around line 339?
> I also note that the platform
> is detected as "generic unix". Do you know what macros gcc defines to
> identify this platform?
Again, from gcc/config/alpha/osf.h:
#define TARGET_OS_CPP_BUILTINS() \
do { \
builtin_define_std ("unix"); \
builtin_define_std ("SYSTYPE_BSD"); \
builtin_define ("_SYSTYPE_BSD"); \
builtin_define ("__osf__"); \
builtin_define ("__digital__"); \
builtin_define ("__arch64__"); \
builtin_define ("_LONGLONG"); \
builtin_define ("__PRAGMA_EXTERN_PREFIX"); \
builtin_assert ("system=unix"); \
builtin_assert ("system=xpg4"); \
/* Tru64 UNIX V5 has a 16 byte long \
double type and requires __X_FLOAT \
to be defined for <math.h>. */ \
if (LONG_DOUBLE_TYPE_SIZE == 128) \
builtin_define ("__X_FLOAT"); \
\
/* Tru64 UNIX V4/V5 provide several ISO C94 \
features protected by the corresponding \
__STDC_VERSION__ macro. libstdc++ v3 \
needs them as well. */ \
if (c_dialect_cxx ()) \
builtin_define ("__STDC_VERSION__=199409L"); \
} while (0)
jon
-- http://c2.com/cgi/wiki?NeverExplain
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk