[boost] Re: Re: [boost.thread] Experimental alternative TLSimplementation

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-19 12:12:31

Yes, that's typical of the error I was talking about.

Bronek Kozicki says he has tracked down the problem for me: adding
"<threading>multi" to boost_thread_lib_base and boost_thread_dll_base
in libs\boost\thread\build\jamfile fixes the problem. I haven't been
able to verify this because I don't have the problem on my machine,
but as it appears related to a problem that I have seen and previously
worked around, I believe he is correct and have committed the change
to cvs. Some questions for bjam gurus:

1) This appears to be a bjam bug, since that option already appears in
a template that is being used by both boost_thread_lib_base and
boost_thread_dll_base. This appears to be the same bug as or related
to one I previously reported (there's another option that's also in
the template that isn't being picked up). Will this be fixed soon?

2) Why is this bug only appearing now on the machines running
regression tests, and not before?

3) Why is the bug still not appearing on my machine? (I generally
update and rebuild bjam whenever I get new source).

Mike

"Roland" <roland.schwarz_at_[hidden]> wrote in message
news:20040819162809.YFWZ11286.viefep13-int.chello.at_at_speedsnail...
> On Wed, 18 Aug 2004 13:59:18 -0400 Michael Glassford
<glassfordm_at_[hidden]> wrote:
>
> > I hope to get time fairly soon. My first priority, though is the
> > regression errors that appeared for statically linked
Boost.Threads
> > while I was gone. Any ideas?
>
> Can you give me any specific pointers?
>
> E.g I found  http://tinyurl.com/48a5t
> Is this a typical error you are talking about?
> What are those xlock and xmutex files? They seemingly try
> to pull in the single threaded lib somehow.
>
> Roland
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>