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@chello.at> wrote in message news:20040819162809.YFWZ11286.viefep13-int.chello.at@speedsnail...
On Wed, 18 Aug 2004 13:59:18 -0400 Michael Glassford <glassfordm@hotmail.com> 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