Linker error with boost_1_36_0
Hi, I built the thread library after downloading "boost_1_36_0.zip". After building the thread library from bjam, when I build the program in VS2008, I get following linker error:- Error 1 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-gd-1_36.lib' What I see in the generated library folder is that boost_thread-vc90-mt-gd-1_36.lib is generated, but the linker is looking for 'libboost_thread-vc90-mt-gd-1_36.lib'. I have already done the required changes in the project properties mentioned at http://www.boost.org/doc/libs/1_36_0/more/getting_started/windows.html . Similar thing happening with Regex library also. The generated lib is boost_regex-vc90-gd-1_36.lib, but the linker is looking for libboost_regex-vc90-gd-1_36.lib. Is there any other settings change required or something else? Thanks, Bhargav.
Adding the following define to your preprocessor definitions should take
care of the problem:
BOOST_ALL_DYN_LINK
This should probably be mentioned in the getting started documentation. I
spent nearly a day on this recently.
Thanks,
Doug Beatty
"kumar bhargav"
DDBeatty writes:
Adding the following define to your preprocessor definitions should take care of the problem:
BOOST_ALL_DYN_LINK
This should probably be mentioned in the getting started documentation. I spent nearly a day on this recently.
It's worth mentioning that the reason this is necessary is because by default only shared libraries are built, but by default static libraries are autolinked. So an alternative to the above preprocessor definition (and the better option in most cases, IMO) is to build static boost libs (either invoke bjam with --build-type=complete or with link=static).
Why is a static library a better option than a dynamic link library in most
cases?
As a Windows developer (don't enjoy labelling myself that way but it is
true) I have always been partial to DLL's. And I think that the "default"
behavior a Windows developer expects is DLL's at least it is for me.
My current opinion is that BOOST_ALL_DYN_LINK should be mentioned in the
"Getting Started on Windows" documentation.
Thanks,
Doug Beatty
Adam Merz
Adding the following define to your preprocessor definitions should take care of the problem:
BOOST_ALL_DYN_LINK
This should probably be mentioned in the getting started documentation. I spent nearly a day on this recently.
It's worth mentioning that the reason this is necessary is because by default only shared libraries are built, but by default static libraries are autolinked. So an alternative to the above preprocessor definition (and the better option in most cases, IMO) is to build static boost libs (either invoke bjam with --build-type=complete or with link=static). _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ----------------------------------------- This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
DDBeatty writes:
Why is a static library a better option than a dynamic link library in most cases?
As a Windows developer (don't enjoy labelling myself that way but it is true) I have always been partial to DLL's. And I think that the "default" behavior a Windows developer expects is DLL's at least it is for me.
My current opinion is that BOOST_ALL_DYN_LINK should be mentioned in the "Getting Started on Windows" documentation.
As I said, it is only my opinion. :-) I'm there are technical merits both ways, but I meant to make it clear my suggestion was subjective. For me, it's the exact opposite -- on Windows I link everything statically by default and use shared libraries only if I have to (WPO is a major factor, especially for libraries that benefit so greatly from additional inlining, as most Boost libs do), whereas on Linux I used shared libraries nearly exclusively.
I know it was your opinion. I am just interested in it because DLL's are
something I just do. I was wondering what reasons you may have for
preferring not to use them.
To that end, I may be displaying some inexcusable ignorance but what is
WPO?
I don't want to get into a long discussion about this. Just curiosity in
passing.
Thanks,
Doug Beatty
Adam Merz
Why is a static library a better option than a dynamic link library in most cases?
As a Windows developer (don't enjoy labelling myself that way but it is true) I have always been partial to DLL's. And I think that the "default" behavior a Windows developer expects is DLL's at least it is for me.
My current opinion is that BOOST_ALL_DYN_LINK should be mentioned in the "Getting Started on Windows" documentation.
As I said, it is only my opinion. :-) I'm there are technical merits both ways, but I meant to make it clear my suggestion was subjective. For me, it's the exact opposite -- on Windows I link everything statically by default and use shared libraries only if I have to (WPO is a major factor, especially for libraries that benefit so greatly from additional inlining, as most Boost libs do), whereas on Linux I used shared libraries nearly exclusively. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ----------------------------------------- This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
DDBeatty writes:
I know it was your opinion. I am just interested in it because DLL's are something I just do. I was wondering what reasons you may have for preferring not to use them.
To that end, I may be displaying some inexcusable ignorance but what is WPO?
I don't want to get into a long discussion about this. Just curiosity in passing.
WPO is Whole Program Optimization, enabled in MSVC with the /GL compiler option (http://msdn.microsoft.com/en-us/library/0zza0de8.aspx) and the /LTCG linker option (http://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx). For code that benefits especially well from inlining, it can be a great boon to performance. That alone is enough for me to use static libs on Windows when I can; PGO (Profile Guided Optimization) only furthers my opinion. :-) Another factor for me is the size of .dlls. My boost_regex-vc90-mt-1_36.dll is 696KB; if I'm only using half the functionality in boost.regex, I don't want to distribute the functionality I'm not using with my application.
Thanks for the info. I hadn't run across that before. I am embarrassed
that I have let myself fall that far behind.
If anyone is reading along and is suffering from the same ignorance I do, I
found another nice article on the subject of these two:
http://msdn.microsoft.com/en-us/library/aa289170.aspx
Thanks,
Doug Beatty
Adam Merz
I know it was your opinion. I am just interested in it because DLL's are something I just do. I was wondering what reasons you may have for preferring not to use them.
To that end, I may be displaying some inexcusable ignorance but what is WPO?
I don't want to get into a long discussion about this. Just curiosity in passing.
WPO is Whole Program Optimization, enabled in MSVC with the /GL compiler option (http://msdn.microsoft.com/en-us/library/0zza0de8.aspx) and the /LTCG linker option (http://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx). For code that benefits especially well from inlining, it can be a great boon to performance. That alone is enough for me to use static libs on Windows when I can; PGO (Profile Guided Optimization) only furthers my opinion. :-) Another factor for me is the size of .dlls. My boost_regex-vc90-mt-1_36.dll is 696KB; if I'm only using half the functionality in boost.regex, I don't want to distribute the functionality I'm not using with my application. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ----------------------------------------- This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
AMDG kumar bhargav wrote:
I built the thread library after downloading "boost_1_36_0.zip".
After building the thread library from bjam, when I build the program in VS2008, I get following linker error:-
Error 1 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-gd-1_36.lib'
This is the static library.
What I see in the generated library folder is that boost_thread-vc90-mt-gd-1_36.lib is generated, but the linker is looking for 'libboost_thread-vc90-mt-gd-1_36.lib'.
boost_thread-vc90-mt-gd-1_36.lib is the import library for boost_thread-vc90-mt-gd-1_36.dll. You can either a) build the static library using bjam ... link=static or b) Use the dynamic libs: compile with -DBOOST_ALL_DYN_LINK In Christ, Steven Watanabe
Steven Watanabe wrote:
You can either a) build the static library using bjam ... link=static or b) Use the dynamic libs: compile with -DBOOST_ALL_DYN_LINK
Or better, when building with bjam, make sure you specify the --build-type=complete option so that all the variants are built. HTH, John.
participants (5)
-
Adam Merz -
DDBeatty＠dstsystems.com -
John Maddock -
kumar bhargav -
Steven Watanabe