|
|
Boost-Build : |
From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2005-09-01 04:13:55
John Maddock ha escrito:
> > OK, I've traced the issue back to the internal GCC macro
> >
> > _GLIBCPP_HAVE_GTHR_DEFAULT
> >
> > not being defined in a GCC config header named bits/c++config.h.
> > I've manually defined that (instructions on the header seem to
> indicate
> > I'm
> > allowed to do it) and now BOOST_HAS_THREADS is defined, but
>
> Are you sure you can do that? As far as I know the only reason why
> that
> macro would not be defined is if your std lib was built single
> threaded, in
> which case threading support in Boost should be turned off. Looking
> around
> my cygwin installation, I see that both gcc-3.2 and 3.3.1 *do* define
> _GLIBCPP_HAVE_GTHR_DEFAULT in their config setups. I don't suppose
> you're
> using Win98 or something are you? I recall this installs different
> cygwin
> runtime from the NT versions that I have here. Failing that are you
> able to
> just update your cygwin installation?
I'm far from being a GCC expert, but I've played a little with -lpthread
and similar
options and seems like my compiler is able to produce multithread safe
code.
Anyway, my real concern has not to do with this particular environment,
please
read on.
> > the problem shows the other way around: I cannot set it off
> > with
> >
> > bjam "-sTOOLS=GCC" "-sBUILD=<threading>single" test_basic
> >
> > Shouldn't BOOST_HAS_THREADS be undef'd in this latter case?
>
> Sigh..... this has come up before, <threading>single doesn't really do
> what
> it says, it just does a build with the compilers default settings, and
> if
> those happen to be multithreaded, then Boost will be as well.
> Defining
> BOOST_DISABLE_THREADS when compiling will really force threading
> support off
> if that's what you want, but you'll have to use that define in any
> projects
> that link to libs built that way, as thread safe and non-thread safe
> libs
> are unlikely to be binary compatible.
>
OK, nevermind. This post stemmed from some experiences of mine regarding
the
following issue, which is what I'm actually interested in, rather than
the multithreading
peculiarities of GCC/Cygwin:
I've commited some changes to multi_index consisting
of multithread-specific code guarded by #ifdef BOOST_HAS_THREADS,
and now I'd like to check whether this is running properly on all the
regression engines.
So, can I assume the following:
If a given regression test environment lists BOOST_HAS_THREADS as
defined
in the config_info output (for instance http://tinyurl.com/e3exr), then
BOOST_HAS_THREADS will be defined in the corresponding multi_index
tests,
provided I've added no special requirements for the threading model in
my Jamfile.
Is this assumption correct?
Thank you,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
--Boundary_(ID_eZXQ2D4rlREUDIYqz2veTQ) Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<p>John Maddock ha escrito:
<blockquote TYPE=CITE> <tt>> OK, I've traced the issue back to
the internal GCC macro</tt>
<br><tt>></tt>
<br><tt>> _GLIBCPP_HAVE_GTHR_DEFAULT</tt>
<br><tt>></tt>
<br><tt>> not being defined in a GCC config header named bits/c++config.h.</tt>
<br><tt>> I've manually defined that (instructions on the header seem to
indicate</tt>
<br><tt>> I'm</tt>
<br><tt>> allowed to do it) and now BOOST_HAS_THREADS is defined, but</tt>
<p><tt>Are you sure you can do that? As far as I know the only reason
why that</tt>
<br><tt>macro would not be defined is if your std lib was built single
threaded, in</tt>
<br><tt>which case threading support in Boost should be turned off.
Looking around</tt>
<br><tt>my cygwin installation, I see that both gcc-3.2 and 3.3.1 *do*
define</tt>
<br><tt>_GLIBCPP_HAVE_GTHR_DEFAULT in their config setups. I don't
suppose you're</tt>
<br><tt>using Win98 or something are you? I recall this installs
different cygwin</tt>
<br><tt>runtime from the NT versions that I have here. Failing that
are you able to</tt>
<br><tt>just update your cygwin installation?</tt></blockquote>
I'm far from being a GCC expert, but I've played a little with -lpthread
and similar
<br>options and seems like my compiler is able to produce multithread safe
code.
<br>Anyway, my real concern has not to do with this particular environment,
please
<br>read on.
<blockquote TYPE=CITE><tt>> the problem shows the other way around: I cannot
set it off</tt>
<br><tt>> with</tt>
<br><tt>></tt>
<br><tt>> bjam "-sTOOLS=GCC" "-sBUILD=<threading>single" test_basic</tt>
<br><tt>></tt>
<br><tt>> Shouldn't BOOST_HAS_THREADS be undef'd in this latter case?</tt>
<p><tt>Sigh..... this has come up before, <threading>single doesn't
really do what</tt>
<br><tt>it says, it just does a build with the compilers default settings,
and if</tt>
<br><tt>those happen to be multithreaded, then Boost will be as well.
Defining</tt>
<br><tt>BOOST_DISABLE_THREADS when compiling will really force threading
support off</tt>
<br><tt>if that's what you want, but you'll have to use that define in
any projects</tt>
<br><tt>that link to libs built that way, as thread safe and non-thread
safe libs</tt>
<br><tt>are unlikely to be binary compatible.</tt>
<br> </blockquote>
OK, nevermind. This post stemmed from some experiences of mine regarding
the
<br>following issue, which is what I'm actually interested in, rather than
the multithreading
<br>peculiarities of GCC/Cygwin:
<p>I've commited some changes to multi_index consisting
<br>of multithread-specific code guarded by #ifdef BOOST_HAS_THREADS,
<br>and now I'd like to check whether this is running properly on all the
regression engines.
<br>So, can I assume the following:
<p>If a given regression test environment lists BOOST_HAS_THREADS as defined
<br>in the config_info output (for instance http://tinyurl.com/e3exr),
then
<br>BOOST_HAS_THREADS will be defined in the corresponding multi_index
tests,
<br>provided I've added no special requirements for the threading model
in my Jamfile.
<p>Is this assumption correct?
<p>Thank you,
<p>Joaquín M López Muñoz
<br>Telefónica, Investigación y Desarrollo</html>
--Boundary_(ID_eZXQ2D4rlREUDIYqz2veTQ)--
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk