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

From: John Maddock (john_at_[hidden])
Date: 2005-06-18 06:31:23

> I tried working my way through the config headers and got TOTALLY lost.
> I tried -H, -E and #warning before I gave up and submitted this missive.
> Even if you can provide the answer "off the top of your head", would you
> mind providing a pointer or two toward the correct path to finding the
> problem?  I'd appreciate that at least as much as the solution itself.

If you look at the line that triggers the #error, you will see it is within 
a block scoped by:

#elif !defined(BOOST_HAS_THREADS)

so the error is triggered by BOOST_HAS_THREADS not being defined.  If you 
now grep through the boost/config headers you will see:

In suffix.hpp:

#if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \
|| defined(_PTHREADS)) && !defined(BOOST_HAS_THREADS)
# define BOOST_HAS_THREADS
#endif

Which is the catch-all case - for gcc on linux, if threading support has 
been enabled in the compiler then _REENTRANT is usually defined, clearly 
it's not in your case, unless that is BOOST_HAS_THREADS is being #undef'ed 
later on by:

#if defined(BOOST_HAS_THREADS) && !defined(BOOST_HAS_PTHREADS)\
&& !defined(BOOST_HAS_WINTHREADS) && !defined(BOOST_HAS_BETHREADS)\
&& !defined(BOOST_HAS_MPTASKS)
# undef BOOST_HAS_THREADS
#endif

Which is there in case the config system doesn't know what kind of threading 
support the platform uses (pthreads win32 threads mptasks etc).  If this is 
the case it's probably because unistd.h doesn't advertise pthread support 
with _POSIX_THREADS.

Also note: for OS'es that are not linux, threading support may get turned on 
unconditionally in gcc.hpp (I don't think this is relevant here), also for 
gcc 3.4 and later, threading support is turned on or else forced off in 
libstdc++.hpp depending on how your std lib was built.

To find out which of the above is the cause the easiest way I find is to 
through some #errors in the preprocessor branches you think may be taken and 
then see if the #error is triggered or not (this is much easier than 
preprocessing the code IMO).

To help you more we probably need:

The gcc version.
The command line that produced the above error.
The output from the config_info program (cd into libs/config/test then 
"bjam -sBUILD="<threading>multi" config_info", then look for output the 
program generated somewhere under 
boost-path/bin/boost/libs/config/test/config_info/ ...some directories... 
/*.output

Hope this gets you further forward.

John.