boost :: thread Build-Fehler (nicht in der Lage zu verknüpfen lib && ungelöst extern)

Question

Ich versuche, ein einfaches Tutorial von boost :: Thread (ver 1,4-3) in VS 2008 zu folgen:

#include <boost/thread/thread.hpp> 

void Func() 
{ 
    // Do something 
} 

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

Während Kompilierung es erzeugt diesen Fehler:

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

, die ich durch das Hinzufügen #define BOOST_ALL_NO_LIB zu lösen haben. aber es gibt mir einen anderen Fehler:

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 

Wer weiß, wie das Problem zu lösen?

Danke.

Answer 1

Sie müssen die Boost-Thread-Bibliothek erstellen und Visual Studio mitteilen, wo sich die Bibliothek befindet. All dies ist in der Dokumentation Erste Schritte (d. H. Getting Started on Windows) dokumentiert. Lesen Sie speziell section 5 und dann section 6.

PS. Sie müssen sicherstellen, dass Ihre Build-Konfiguration mit dem übereinstimmt, für das VS festgelegt wurde. Das Erste Schritte erklärt die verschiedenen Build-Optionen.

Answer 2

Ich denke, eine tiefere Antwort als "Lies das F * cking Manual" könnte hilfreich sein!

Diese Art von Link-Fehler ist ein Hinweis, dass Sie versuchen, eine inkompatible Boost-Bibliothek zu verknüpfen.

Ich habe das, wenn ich versehentlich eine 32-Bit-Boost-Thread-Bibliothek erstellt, wenn ich dachte, ich baute eine 64-Bit-Bibliothek. Es hat eine Weile gedauert, bis du herausgefunden hast, dass du einen subtilen Fehler gemacht hast, wenn du --address-model=64 als bjam-Kommandozeilenparameter sagst. Der Parameter address-model darf NICHT das Präfix -- haben. Leider informiert bjam Sie nicht, wenn es die falsche Syntax sieht.

Sie können das Programm dumpbin verwenden, um die von Ihrer Bibliothek bereitgestellten Symbole zu überprüfen, im Gegensatz zu den Symbolen, die der Linker sagt, dass sie nicht gelöst sind. Ich fand, dass die Bibliothekssymbole mit __thiscall und nicht __cdecl dekoriert wurden. Dies ist ein schreiender guter Hinweis auf das Architektur-Missverhältnis. Der Microsoft-Compiler verwendet das Funktionsaufrufprotokoll __thiscall für 32-Bit-Builds, aber es verwendet __cdecl für 64-Bit-Builds. Ja, die Microsoft-Dokumentation ist hier ein wenig schwach !!

Der beste Weg, um eine .lib oder .dll zu sehen, wie es gebaut wurde, ist die Verwendung des Dumpbin-Programms. Hier ein Beispiel:

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

Sie haben werde den Namen der Bibliothek anzupassen anzupassen, was Sie verbindet natürlich. Dadurch wird Ihnen eindeutig angezeigt, ob die .lib- oder .dll-Datei für x86 (32-Bit) oder x64 (64-Bit) vorgesehen ist.