Re: [boost] Boost.config not recognize threading support enabled?

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.  ;)

Yes.

> - 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):
> </snippet>
> *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) && 
defined(_GLIBCPP_HAVE_GTHR_DEFAULT)
#define BOOST_HAS_THREADS
#endif

Any closer?

John.