Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk