And so on to my next problem, which again turned out to be due to my good friend Boost.
Background:
- Visual Studio 2008
- 32bit Project containing a managed CLR wrapper on some unmanaged C++ libraries
- The unmanaged libraries reference a version of Boost compiled using Visual Studio 2005.
- Messages at compilation time:
Linking to lib file: boost_thread-vc90-mt-gd-1_39.lib - Error message:
fatal error LNK1104: cannot open file 'boost_thread-vc90-mt-gd-1_39.lib'
The more sharp-sighted amongst you will have quickly noticed the reference to “vc90″ in the lib file name, implying the libraries were compiled with Visual Studio 2008. This is odd because the libraries are most definitely called boost*vc80*.lib. Where was Visual Studio picking up this reference to vc90? There was no reference to vc90 in the project properties, which implies that Visual Studio was dragging this out of thin air.
After a fair amount of investigation, my suspicions finally fell up the Boost includes. The cause had to be something in the boost include files that wass forcing the assumption that the libraries had been compiled with VS2008. A quick search revealed the following culprit: include/boost/config/auto_link.hpp
The auto_link.hpp code includes a section that searches for the _MSC_VER environment variable (which is set by Visual Studio). If BOOST_LIB_TOOLSET is not predefined, _MSC_VER is used to infer the relevant compiler version (vc80, vc90 etc). The BOOST_LIB_TOOLSET property is then used to construct the file names for the libs to be linked. Thus, since I was using VS2008, BOOST_LIB_TOOLSET defaulted to vc90.
The solution was to add the following to the Preprocessor Definitions: BOOST_LIB_TOOLSET=vc80
Once set, _MSC_VER was ignored and everything compiled as expected.
