From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-06-27 12:14:10
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> Behalf Of John Maddock
> Sent: Thursday, June 23, 2005 3:04 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.config not recognize threading support
> > [Dick] My primary reservation about this approach is based upon my
> > assumption that the "macro-that-identifies-linux-on-arm" would be an
> > attribute of the compiler. I still can't get used to the idea that
> > multi-threaded or single-threaded is compiled into the gcc
> > cross-compiler itself, while little-endian and big-endian are
> > line switches. %>[ The multiplicity of targets and threading models
> > might require a number of such tests that would be difficult to
> Sure? _GLIBCPP_HAVE_GTHR_DEFAULT tells you whether the compiler and
> were compiled with threading support or not, as long as the change is
> limited to linux on arm, just how many such tests would we need?
[Dick] Nope, not sure at all. I overlooked "limited to linux on arm".
(At any given time our "build" currently uses six instances of gcc -
various PowerPC, x86 look-a-likes, DSPs, etc. - and I'll worry about
those later.) Yes, your suggestion to put the test in libstdcpp3.hpp
seems like it would work nicely. As a no-longer-lurking newbie, can I
do something or do I sit back and wait for someone to add that test?
> >> Any closer?
> > [Dick] I'm of two minds about the following suggestion: it's either
> > kludge or introduces a certain pleasing symmetry. ;)
> > Since BOOST_DISABLE_THREADS is used to unconditionally disable
> > the user-wielded imperative BOOST_ENABLE_THREADS (tested at the same
> > place in suffix.hpp) would [almost] unconditionally define
> > BOOST_HAS_THREADS - subject only to the existing verification that
> > threading API has been identified and is recognized.
> Or you could just spell your new macro BOOST_HAS_THREADS :-)
> No changes needed then.
[Dick] Once again I yelled before I was bit. I'm haven't been able to
get bjam --v2 to pass BOOST_HAS_THREADS to the compiler so I ass-u-me-D
it was some magic cookie that was being #undefD in preparation for use
as a flag. Dumb. I'll go back to the boost.build list with this now.
Thanks for the mentoring.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk