Compiler wants to link to threading library all of a sudden

Hello Boost users
I wonder if anyone can help me please. I have just updated my boost
install to svn head to take advantage of some bugfixes. Now the
compiler complains that it can't find
libboost_thread-vc90-mt-sgd-1_49.lib. But I am not trying to use the
threading libraries - my boost includes are:
#include

On Tue, Feb 07, 2012 at 01:54:30PM +0000, Crispin Cooper wrote:
Hello Boost users
I wonder if anyone can help me please. I have just updated my boost install to svn head to take advantage of some bugfixes. Now the compiler complains that it can't find libboost_thread-vc90-mt-sgd-1_49.lib. But I am not trying to use the threading libraries - my boost includes are:
#include
#include #include #include #include #include #include #include
This thread on boost@ might be relevant: http://lists.boost.org/Archives/boost/2012/01/189698.php I would reckon that shared_ptr most probably has some thread safety primitives, and the other types might have internal mutexes as well. -- Lars Viklund | zao@acc.umu.se

On 07/02/2012 15:56, Lars Viklund wrote:
I would reckon that shared_ptr most probably has some thread safety primitives, and the other types might have internal mutexes as well. I just tested shared_ptr on its own - it doesn't try to link.
Is this something that is changing with the previous or current release? Won't additional locks cause overheads, and is there a global #define I can set to disable them? Crispin -- Dr Crispin Cooper Sustainable Places Research Institute Cardiff University

On Thu, Feb 9, 2012 at 12:54 AM, Crispin Cooper
On 07/02/2012 15:56, Lars Viklund wrote:
I would reckon that shared_ptr most probably has some thread safety primitives, and the other types might have internal mutexes as well.
I just tested shared_ptr on its own - it doesn't try to link.
Is this something that is changing with the previous or current release? Won't additional locks cause overheads, and is there a global #define I can set to disable them?
Crispin
-- Dr Crispin Cooper Sustainable Places Research Institute Cardiff University
______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**usershttp://lists.boost.org/mailman/listinfo.cgi/boost-users
I believe the cause of the behaviour you're observing is not necessarily additional locks, but instead that the implementation of boost::mutex has changed (to add a C++11 interface or something similar), and in the process has moved from header-only to requiring linking. This is all from my memory of skimming the developer list though, so you may want to check out the archives for more information.

Crispin Cooper wrote:
Hello Boost users
I wonder if anyone can help me please. I have just updated my boost install to svn head to take advantage of some bugfixes. Now the compiler complains that it can't find libboost_thread-vc90-mt-sgd-1_49.lib. But I am not trying to use the threading libraries - my boost includes are:
#include
#include #include #include #include #include #include #include Have any of these changed such that they require prebuilt libraries? Or is including boost from the head revision somehow different to a released version in this manner?
Do you mean the 1_49_0 beta based on the lib names above? There was some discussion recently on the dev list about this but I don't remember which lib[s] were involved. I thought the were going to fix it in the 1.49 release which is a few weeks away. Jeff

On 08/02/2012 14:39, Jeff Flinn wrote:
Do you mean the 1_49_0 beta based on the lib names above? There was some discussion recently on the dev list about this but I don't remember which lib[s] were involved. I thought the were going to fix it in the 1.49 release which is a few weeks away. I was using svn head, but just tried against 1_49_0_beta1. Same bug occurs. If it were fixed in 1.49 that would be great news for me!
Crispin -- Dr Crispin Cooper Sustainable Places Research Institute Cardiff University
participants (4)
-
Crispin Cooper
-
Jeff Flinn
-
Joshua Boyce
-
Lars Viklund