błąd kompilacji boost :: thread (w stanie połączyć lib && nierozwiązane zewnętrznych)

Question

Staram się śledzić prosty tutorial boost :: wątek (ver 1.4-3) w VS 2008:

#include <boost/thread/thread.hpp> 

void Func() 
{ 
    // Do something 
} 

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

czasie kompilacja produkuje ten błąd:

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

które muszę rozwiązać dodając #define BOOST_ALL_NO_LIB. Jednak to daje mi kolejny błąd:

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 

Czy ktoś wie jak rozwiązać ten problem?

Dzięki.

Answer 1

Musisz zarówno zbudować bibliotekę wątku doładowania, jak i poinformować program Visual Studio, gdzie znajduje się biblioteka. Wszystko to jest udokumentowane w dokumentacji Getting Started (tj. Getting Started on Windows). Dokładniej przeczytaj section 5, a następnie section 6.

PS. Musisz się upewnić, że twoja konfiguracja kompilacji pasuje do tego, do czego masz ustawiony VS. Pierwsze kroki wyjaśniają różne opcje kompilacji.

Answer 2

Uważam, że odpowiedź głębsza niż "Przeczytaj instrukcję F * cking" może być pomocna!

Ten rodzaj błędu łącza jest wskazówką, że próbujesz połączyć niezgodną bibliotekę Boost.

Otrzymałem to, gdy przez pomyłkę zbudowałem 32-bitową bibliotekę wątków, gdy myślałem, że buduję bibliotekę 64-bitową. Zajęło trochę czasu, aby dowiedzieć się, że kiedy mówisz --address-model=64 jako parametr linii poleceń bjam popełniłeś subtelny błąd. Parametr address-model NIE może mieć prefiksu --. Niestety bjam nie informuje cię, gdy widzi niepoprawną składnię.

Możesz użyć programu dumpbin do sprawdzenia symboli dostarczonych przez twoją bibliotekę, w przeciwieństwie do symboli, które linker mówi, są nierozwiązane. Zauważyłem, że symbole biblioteczne zostały ozdobione __thiscall, a nie __cdecl. To krzykliwa, dobra wskazówka dotycząca niedopasowania architektury. Kompilator Microsoft używa protokołu wywoływania funkcji __thiscall dla wersji 32-bitowych, ale korzysta z wersji __cdecl dla kompilacji 64-bitowych. Tak, dokumentacja Microsoft jest tu trochę słaba !!

Najlepszym sposobem na sprawdzenie pliku .lib lub .dll, aby zobaczyć, jak został zbudowany, jest użycie programu dumpbin. Oto przykład:

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

Będziesz musiał zmienić nazwę biblioteki odpowiednio do tego, co łączysz. To pokaże ci jednoznacznie, czy plik .lib, czy plik .dll jest kierowany na x86 (który jest 32-bitowy) lub x64 (64-bitowy).