impulso :: hilo error de generación (incapaz de enlazar lib && sin resolver externo)

Question

Estoy intentando seguir un sencillo tutorial de impulso :: hilo (ver 1.4-3) en VS 2008:

#include <boost/thread/thread.hpp> 

void Func() 
{ 
    // Do something 
} 

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

Durante la compilación se produce este error:

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

, que tengo que resolver mediante la adición de #define BOOST_ALL_NO_LIB. Sin embargo, me da otro 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 

¿Alguien sabe cómo resolver el problema?

Gracias.

Answer 1

Necesita construir la biblioteca Boost Thread y decirle a Visual Studio dónde está la biblioteca. Todo esto está documentado en la documentación de Getting Started (es decir, Getting Started on Windows). Específicamente, lea section 5 y luego section 6.

PS. Debe asegurarse de que su configuración de compilación coincida con la que tiene VS establecido. El Getting Started explica las diversas opciones de compilación.

Answer 2

¡Creo que una respuesta más profunda que "Leer el manual de F * cking" podría ser útil!

Este tipo de error de enlace es una pista de que está intentando vincular una biblioteca incompatible de Boost.

Obtuve esto cuando erróneamente construí una biblioteca de subprocesos de 32 bits cuando creí que estaba construyendo una biblioteca de 64 bits. Tardó un tiempo en darse cuenta de que cuando dice --address-model=64 como un parámetro de línea de comando bjam, ha cometido un error sutil. El parámetro address-model NO debe tener el prefijo --. Lamentablemente, bjam no te informa cuando ve la sintaxis incorrecta.

Puede usar el programa dumpbin para verificar los símbolos proporcionados por su biblioteca, frente a los símbolos que el enlazador dice que no están resueltos. Encontré que los símbolos de la biblioteca estaban decorados con __thiscall y no con __cdecl. Esta es una buena pista de gritos de la falta de armonía de la arquitectura. El compilador de Microsoft usa el protocolo de llamada de función __thiscall para las compilaciones de 32 bits, pero usa __cdecl para compilaciones de 64 bits. Sí, ¡la documentación de Microsoft es un poco débil aquí!

La mejor manera de comprobar un archivo .lib o .dll para ver cómo se creó es utilizar el programa dumpbin. He aquí un ejemplo:

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

Vas a tener que ajustar el nombre de la biblioteca para que se adapte lo que establece el vínculo por supuesto. Esto le mostrará inequívocamente si el archivo .lib o .dll está dirigido a x86 (que es de 32 bits) o x64 (64 bits).