boost::thread build error (unable to link lib && unresolved external)

Question

I'm trying to follow a simple tutorial of Boost::Thread (ver 1.4-3) in VS 2008:

#include <boost/thread/thread.hpp>

void Func()
{
    // Do something
}

void main()
{
    boost::thread _thrd(&Func);
    _thrd.join();
    ....
}

During compilation it produces this error:

Error 1 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-gd-1_43.lib' CConsole

which I have to resolve by adding #define BOOST_ALL_NO_LIB. However, it gives me another error:

Error 3 fatal error LNK1120: 2 unresolved externals 
C:\xx\Documents\Visual Studio 2008\Projects\CConsole\Debug\CConsole.exe


Error 1 error LNK2019: unresolved external symbol "public: __thiscall boost::thread::~thread(void)" (??1thread@boost@@QAE@XZ) referenced in function _wmain CConsole.obj


Error 2 error LNK2019: unresolved external symbol "private: void __thiscall boost::thread::start_thread(void)" (?start_thread@thread@boost@@AAEXXZ) referenced in function "public: __thiscall boost::thread::thread<void (__cdecl*)(void)>(void (__cdecl*)(void),struct boost::thread::dummy *)" (??$?0P6AXXZ@thread@boost@@QAE@P6AXXZPAUdummy@01@@Z) CConsole.obj

Does anyone know how to resolve the issue?

Thanks.

Answer 1

I think a deeper answer than "Read the F*cking Manual" might be helpful!

This kind of link error is a clue that you're trying to link an incompatible Boost library.

I got this when I mistakenly built a 32 bit Boost thread library when I thought I was building a 64 bit library. It took a while to figure out that when you say --address-model=64 as a bjam command line parameter you have made a subtle mistake. The address-model parameter must NOT have the -- prefix. Unfortunately bjam does not inform you when it sees the incorrect syntax.

You can use the dumpbin program to check the symbols provided by your library, versus the symbols that the linker says are unresolved. I found that the library symbols were decorated with __thiscall and not __cdecl. This is a screaming good clue of the architecture mismatch. The Microsoft compiler uses the __thiscall function call protocol for 32-bit builds, but it uses __cdecl for 64-bit builds. Yes, the Microsoft documentation is a little weak here!!

The best way to check a .lib or .dll to see how it was built is to use the dumpbin program. Here's an example:

dumpbin /headers libboost_thread-vc100-mt-gd-1_45.lib | findstr machine

You'll have to adjust the library name to suit what you're linking of course. This will show you unambiguously whether the .lib or .dll is targeted for x86 (which is 32-bit) or x64 (64-bit).