boost auto linking feature, force static link?
Hi. I'm using vs2008 and the way I have my project set up is that there is a common framework which I build into a static library, and this framework uses boost signals which I've built into a static library as well. The thing is that when I compile the test project that uses the framework, it tries to link with the dynamic signals library. My framework lib also doesnt try and link with the static lib of signals. I went into the auto link.hpp boost file, and saw that if _DLL is defined then it will link with dynamic lib, else it will use the static lib. I tried removing _DLL from the preprocessor visual studio defines and the same thing happens. Is there a way to force boost to auto link with the static lib? I know there's a way to force link with dynamic lib but wondering if the opposite is possible. Thanks
Ali F wrote:
Hi.
I'm using vs2008 and the way I have my project set up is that there is a common framework which I build into a static library, and this framework uses boost signals which I've built into a static library as well. The thing is that when I compile the test project that uses the framework, it tries to link with the dynamic signals library.
Are you sure?
My framework lib also doesnt try and link with the static lib of signals. I went into the auto link.hpp boost file, and saw that if _DLL is defined then it will link with dynamic lib,
No: _DLL is used to determine which build variant is used (which MSVC runtime library the code is built against), not whether to link to a dll or static library build of Boost.Signals.
else it will use the static lib. I tried removing _DLL from the preprocessor visual studio defines and the same thing happens.
Don't do that, the define is there for a reason.
Is there a way to force boost to auto link with the static lib? I know there's a way to force link with dynamic lib but wondering if the opposite is possible.
It should be doing that already: which library is it trying to link too? Build with BOOST_LIB_DIAGNOSTIC defined if you're not sure and there'll be a compiler message with the library name. HTH, John.
Are you sure?
Hi, yes I'm pretty sure. I used the BOOST_DIAGNOSTIC define and while my framework lib is being built, the output is "Linking to lib file: libboost_signals-vc90-mt-gd-1_35.lib"
No: _DLL is used to determine which build variant is used (which MSVC runtime library the code is built against), not whether to link to a dll or static library build of Boost.Signals.
Oh, ok, when I was looking through the source I saw that #if defined(_DLL) then variant="gd" else variant="sgd" so I just assumed that was where teh decision was being made, since I want boost to link to the sgd variant. Thanks for the input.
Ali F wrote:
Are you sure?
Hi, yes I'm pretty sure. I used the BOOST_DIAGNOSTIC define and while my framework lib is being built, the output is "Linking to lib file: libboost_signals-vc90-mt-gd-1_35.lib"
That *is* the static version of Boost.Signals built against the debug-dll runtime.
No: _DLL is used to determine which build variant is used (which MSVC runtime library the code is built against), not whether to link to a dll or static library build of Boost.Signals.
Oh, ok, when I was looking through the source I saw that #if defined(_DLL) then variant="gd" else variant="sgd" so I just assumed that was where teh decision was being made, since I want boost to link to the sgd variant.
The sgd variant is for use when your code generation options use the debug static runtime library ie with /MTd, if the autolink header was looking for the -gd variant then you're probably building with /MDd in which case the -gd variant is the one you want. BTW the signals dll import libraries don't have the "lib" prefix on their names. HTH, John.
Ah, ok so the extension at the end of the boostlib names is for the vc runtime only. But now I'm a little confused. I changed the vc runtime library to use the MTd and everything compiled fine - ie the framework lib and the test app. Why is it that when I compile with MDd the linker tells me it cannot open libboost_signals-vc90-mt-gd-1_35.lib? I built everything with bjam and the vc directories are set, and it doesnt give me the same message whem I compile the framework lib, just for the test app. Also, for bjam, I used the following just incase that would help bjam release debug stage and bjam release debug link=static runtime-link=static stage
BTW the signals dll import libraries don't have the "lib" prefix on their names.
I'm sorry, are you saying that the libraries output by the whole boot.build process of the signals library do not end in a .lib? Thanks for taking the time out.
BTW the signals dll import libraries don't have the "lib" prefix on their names.
I'm sorry, are you saying that the libraries output by the whole boot.build process of the signals library do not end in a .lib?
No, they don't have the _pre_ fix "lib". They are just called boost_... instead of libboost_... If you link statically to boost you need libboost_....lib, if you want to dynamically link, you need boost_....lib and, of course, the corresponding DLL. Regards, Rainer
Ali F wrote:
Ah, ok so the extension at the end of the boostlib names is for the vc runtime only.
Yep.
But now I'm a little confused. I changed the vc runtime library to use the MTd and everything compiled fine - ie the framework lib and the test app. Why is it that when I compile with MDd the linker tells me it cannot open libboost_signals-vc90-mt-gd-1_35.lib?
Does that file exist on disk?
I built everything with bjam and the vc directories are set, and it doesnt give me the same message whem I compile the framework lib, just for the test app. Also, for bjam, I used the following just incase that would help
bjam release debug stage
and
bjam release debug link=static runtime-link=static stage
Try: bjam release debug link=static stage or bjam --build-type=complete to build all possible variations.
BTW the signals dll import libraries don't have the "lib" prefix on their names.
I'm sorry, are you saying that the libraries output by the whole boot.build process of the signals library do not end in a .lib?
No that they don't *begin* with a "lib" *prefix*. HTH, John.
Does that file exist on disk?
Most definetly.
bjam --build-type=complete
Thanks a lot John. That did it. So it was because I was building the libraries wrong... This boost.build is a little confusing. I'm still not entirely sure what I was doing wrong actually. Was it just bjam release debug stage as opposed to what you suggested? I thought bjam builds static libs automatically. And if it was prefixed with 'lib' then it was static right? So why did the above fix it? I'm sorry I'm so dense, hopefully this one last reply with lodge this in my head permanently.
No that they don't *begin* with a "lib" *prefix*.
heh, oops.
Ali F wrote:
Does that file exist on disk?
Thanks a lot John. That did it. So it was because I was building the libraries wrong... This boost.build is a little confusing. I'm still not entirely sure what I was doing wrong actually. Was it just bjam release debug stage as opposed to what you suggested? I thought bjam builds static libs automatically. And if it was prefixed with 'lib' then it was static right? So why did the above fix it? I'm sorry I'm so dense, hopefully this one last reply with lodge this in my head permanently.
Boost.Build changed it's default behaviour from 1.34 to 1.35 to only build a single release variant by default: this suites Unix flavours, but is pretty useless for MSVC :-( And yes you were building static libraries before, just not the right ones to match the code-generation options you were using. John.
participants (3)
-
Ali F -
John Maddock -
Rainer Thaden