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