From: John Maddock (john_at_[hidden])
Date: 2005-06-22 06:02:03
> - BOOST_HAS_PTHREADS is defined in posix_features.hpp after <unistd.h>
> is included. I had hoped this was a good thing. ;)
> - Then we get to suffix.hpp. BOOST_HAS_PTHREADS is defined and
> BOOST_DISABLE_THREADS is !defined. So far, so good. However, because
> none of _REENTRANT, _PTHREADS, __MT__, and __MT are defined,
> BOOST_HAS_THREADS is still not defined. Consequently, on the way out,
> BOOST_HAS_PTHREADS is undef'D.
> Now that I see how BOOST_HAS_THREADS is not defined, I've moved into the
> dark nether region of the-land-way-over-my-head.
> I'm tempted to add BOOST_HAS_PTHREADS to the list of macros tested here:
> <snippet file=suffix.hpp>
> // Turn on threading support if the compiler thinks that it's in
> // multithreaded mode. We put this here because there are only a
> // limited number of macros that identify this (if there's any missing
> // from here then add to the appropriate compiler section):
> *BUT*, that little parenthetical admonition strongly suggests this file
> is not to be modified - ever again. ;) Besides: there must have been
> a reason for defining BOOST_HAS_PTHREADS without automatically
> concluding BOOST_HAS_THREADS.
Yes: for some compilers (including gcc on some platforms), just because the
platform has pthreads, and advertises it's presence in unistd.h, this does
*not* mean that the C++ compiler can generate thread aware/safe code unless
special measures are taken (a special command line option usually, for
example -mthreads on cygwin), or not at all in some cases (gcc on SGI Irix
for example). C++ compiles have to take special care when generating
exception handling and / or RTTI code that may involve hidden globals, in
order for them to be thread safe. This is not the case for C compiles, and
remember that unistd.h is a C header!
> Apparently a similar problem was fixed in the past
> (http://lists.boost.org/MailArchives/boost/msg19675.php) by adding an
> unconditional define of BOOST_HAS_THREADS to metrowerks.hpp. But that
> clearly won't work with gcc.hpp.
> I am sorely in need of guidance. Where should I go from here?
> [Dick] Hey, that's a NEAT tool! (Unfortunately the "default" compiler
> is gcc 3.4 and defines _REENTRANT. %>[ ) I'm going back through the
> docs now to figure out how to invoke the cross-compiler but hoping the
> above info might yield and answer.
Sorry, I forgot that you were cross compiling: you could try compiling that
file manually with your cross compiler, and transfering the executable to an
arm machine, but don't forget to use any compiler options like -pthread that
the cross compiler may accept: this is *really* under-documented in the gcc
manual, we have an open gcc bug report on this, but no one seems to want to
fix this at present :-(
You could try g++ -dumpspecs to find out what if any threading options your
cross compiler may recognise.
Failing everything else, I think the way to handle this is with something
like this in libstdcpp3.hpp:
#if defined(macro-that-identifies-linux-on-arm) &&
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk