Re: [boost] Boost.config not recognize threading support enabled?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Saturday, June 18, 2005 4:31 AM To: boost@lists.boost.org Subject: Re: [boost] Boost.config not recognize threading support enabled?
<snip>
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 <snip> 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.
[Dick] "/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2/bin/arm-so ftfloat-linux-gnu-c++" -v Reading specs from /opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2/lib/gcc-lib /arm-softfloat-linux-gnu/3.3.3/specs Configured with: /data/work/OMAP/crosstool/crosstool-0.28-rc37/build/arm-softfloat-linux- gnu/gcc-3.3.3-glibc-2.3.2/gcc-3.3.3/configure --target=arm-softfloat-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2 --with-float=soft --with-headers=/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2. 3.2/arm-softfloat-linux-gnu/include --with-local-prefix=/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-gli bc-2.3.2/arm-softfloat-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 3.3.3 __GLIBCPP__ is 20040214 and __GLIBCXX__ is not defined. I 'peppered' the headers with #warningS and determined that: - BOOST_HAS_THREADS is not defined in gcc.hpp because linux, __linux & __linux__ are all defined. - BOOST_STDLIB_CONFIG is defined as "boost/config/stdlib/libstdcpp3.hpp" in select_stdlib_config.hpp. But BOOST_HAS_THREADS is not defined in libstdcpp3.hpp because __GLIBCXX__ is not defined. - 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): </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. 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?
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
program generated somewhere under boost-path/bin/boost/libs/config/test/config_info/ ...some
[Dick] "/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.3.3-glibc-2.3.2/bin/arm-so ftfloat-linux-gnu-c++" -I/usr/local/boost_1_32_0 -pthread test.cpp the directories...
/*.output
[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.
Hope this gets you further forward.
John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[Dick] Your help with this is sincerely appreciated. Thank you.
- 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.
participants (2)
-
BRIDGES Dick -
John Maddock