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.

Marciano

Not all parts of Boost are header-only. You need to include the appropriate cpp files (not recommended) or (generally better) build a static library to which you can link your project. – Macaw

Hi stinky472, I do link the lib file, however I notice the file name is bit difference, so I rename the file and it seems to work. Thanks. – Marciano

the name of the lib changes depending on what kind of lib you build: static/dynamic, debug/release, single/multithreading.... You should NOT change the name, but build the correct lib that you need using parameters to the bjam-builder. – Chummy

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).

Furfural

I thought that if I had compiled boost using a "Visual Studio 2005 x64 Win64 Command Prompt" that I would have 64-bit boost libraries. Then I kept running into these kinds of linking errors. It took a lot of googling to find this answer. Thanks! .\b2 address-model=64 stage – Reductase

These kinds of problems also stem from the fact that boost by default uses the same directory for all libs and that it doesn't change the file name depending on the architecture. This way you can easily overwrite x86 libs with i64 ones and vice versa. – Berwickupontweed

Answer 2

You need to both build the Boost Thread library and tell Visual Studio where the library is. All this is documented in the Getting Started documentation (i.e. Getting Started on Windows). Specifically read section 5 and then section 6.

PS. You need to make sure your build configuration matches what you have VS set to. The Getting Started explains the various build options.

Consequence