Auto-Linking in Visual Studio 2008
Hi, I recently began using boost in a project on Windows using MS Visual Studio 9.0 2008 using CMake, i.e. the project setup is auto-generated using the correct boost libraries as link targets. In my project, I link to boost_thread*.lib, which should be the import library for boost_thread*.dll. However, when I compile the project, the I get the following linking error:
Error 43 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_48.lib' rsb-chat-1 rsb-chat-1
So it seems necessary to have the static library present as well when linking the executable. At first I thought this was the default auto-linking behavior described in the documentation, i.e. static linking. However, once all needed static libraries are supplied, the final executable still needs the dynamic boost_*.dll libraries. This did not seem right to me... Now, when I disable auto-linking using
#define BOOST_ALL_NO_LIB
the linker will not try to link the static libboost_thread*.lib, but instead use the boost_thread*.lib that was defined in the project settings. I couldn't find any documentation on this specific auto-linking behavior. * Is this expected behavior? Maybe MSVS-specific behavior? * Does the presence of the static library actually preclude some dynamic linking from occurring, thus making my executable bigger? * Or does the static library basically just need to be present and auto-linking will actually not use it when it's not appropriate? * Or does auto-linking mix and match, i.e. in my original case, when I supplied the static libraries: Did it link some functions statically, while others dynamically? Thanks, Robert
I recently began using boost in a project on Windows using MS Visual Studio 9.0 2008 using CMake, i.e. the project setup is auto-generated using the correct boost libraries as link targets. In my project, I link to boost_thread*.lib, which should be the import library for boost_thread*.dll.
However, when I compile the project, the I get the following linking error:
Error 43 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_48.lib' rsb-chat-1 rsb-chat-1
So it seems necessary to have the static library present as well when linking the executable. At first I thought this was the default auto-linking behavior described in the documentation, i.e. static linking. However, once all needed static libraries are supplied, the final executable still needs the dynamic boost_*.dll libraries. This did not seem right to me...
When using .dlls in this way the .lib is needed and is called an import library. Linking against an import library does not remove you from needing the .dll. John
Hi John, On 2012/01/03 22:33, John Drescher wrote:
When using .dlls in this way the .lib is needed and is called an import library. Linking against an import library does not remove you from needing the .dll. I'm aware of this. I was wondering why the *static* library was still needed for auto-linking and whether it would mix static and dynamic dependencies, i.e. decide by some heuristic when one of the libraries is /better/ and use it instead of a clean static-only or dynamic-only linking.
Thanks, Robert
I recently began using boost in a project on Windows using MS Visual Studio 9.0 2008 using CMake, i.e. the project setup is auto-generated using the correct boost libraries as link targets. In my project, I link to boost_thread*.lib, which should be the import library for boost_thread*.dll.
However, when I compile the project, the I get the following linking error:
Error 43 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_48.lib' rsb-chat-1 rsb-chat-1
So it seems necessary to have the static library present as well when linking the executable. At first I thought this was the default auto-linking behavior described in the documentation, i.e. static linking. However, once all needed static libraries are supplied, the final executable still needs the dynamic boost_*.dll libraries. This did not seem right to me...
Are the dynamic libraries being specified on the linker command line? You absolutely should not be linking to both (ie both auto-linking and specifying the lib's on the command line). So either disable auto-linking with BOOST_ALL_NO_LIB (you will need to enable dynamic linking as well with BOOST_ALL_DYN_LINK if you want to use the DLL's), or remove the library dependencies in CMake and let the auto-linking do it's work. If you take the former route, be *very* careful that your build script picks the correct lib variant, otherwise you're likely to see crashes and other strange hard to track down behavior..... HTH, John.
Hi John, On 2012/01/04 12:58, John Maddock wrote:
Are the dynamic libraries being specified on the linker command line?
No, the dynamic libraries are not. The import libraries are, however.
You absolutely should not be linking to both (ie both auto-linking and specifying the lib's on the command line).
Ok, got that. This was why I was asking, because the CMake script I currently use do this. Probably because the makers use mingw, where the website states auto-linking doesn't work... So the authors might be unaware of the problem.
So either disable auto-linking with BOOST_ALL_NO_LIB (you will need to enable dynamic linking as well with BOOST_ALL_DYN_LINK if you want to use the DLL's), or remove the library dependencies in CMake and let the auto-linking do it's work. I already did the former. Basically, I'm pulling in dependencies from some other library which depends on boost. So when I include its required libraries in my CMake script, the variable will contain boost as well...
If you take the former route, be *very* careful that your build script picks the correct lib variant, otherwise you're likely to see crashes and other strange hard to track down behavior.....
I'm wondering about this one. Basically, my situation is like this: I have debug and release builds of dynamic and import boost libs. I built the intermediate library (the one from above) using release. Now, when I compile my own project for debug, the executable will crash (within a function of the intermediate library). However, when I compile my project for release, everything goes smoothly. Would this be the kind of situation you mentioned above? Because I'm not quite sure where this problem would be coming from, seeing as the executables only require the correct libraries, i.e. my debug executable will use boost debug libraries, and release libraries of my other dependent library. Whereas release will require release boost libs and release dependency... The exception I encounter in debug is actually boost::thread::interrupted_exception, IIRC. Thanks, Robert
On Thu, Jan 5, 2012 at 3:55 PM, Robert Abel
Hi John,
On 2012/01/04 12:58, John Maddock wrote:
Are the dynamic libraries being specified on the linker command line?
No, the dynamic libraries are not. The import libraries are, however.
You absolutely should not be linking to both (ie both auto-linking and specifying the lib's on the command line).
Ok, got that. This was why I was asking, because the CMake script I currently use do this. Probably because the makers use mingw, where the website states auto-linking doesn't work... So the authors might be unaware of the problem.
So either disable auto-linking with BOOST_ALL_NO_LIB (you will need to enable dynamic linking as well with BOOST_ALL_DYN_LINK if you want to use the DLL's), or remove the library dependencies in CMake and let the auto-linking do it's work. I already did the former. Basically, I'm pulling in dependencies from some other library which depends on boost. So when I include its required libraries in my CMake script, the variable will contain boost as well...
If you take the former route, be *very* careful that your build script picks the correct lib variant, otherwise you're likely to see crashes and other strange hard to track down behavior.....
I'm wondering about this one. Basically, my situation is like this:
I have debug and release builds of dynamic and import boost libs. I built the intermediate library (the one from above) using release. Now, when I compile my own project for debug, the executable will crash (within a function of the intermediate library). However, when I compile my project for release, everything goes smoothly. Would this be the kind of situation you mentioned above?
Yes. Microsoft Debug CRT is not compatible with the Release CRT so you can not safely mix debug and release dlls and exes.
Because I'm not quite sure where this problem would be coming from, seeing as the executables only require the correct libraries, i.e. my debug executable will use boost debug libraries, and release libraries of my other dependent library. Whereas release will require release boost libs and release dependency... The exception I encounter in debug is actually boost::thread::interrupted_exception, IIRC.
Thanks,
Robert _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- John M. Drescher
participants (3)
-
John Drescher -
John Maddock -
Robert Abel