Linker error LNK2019 lors de la liaison de Boost 1.51.0 de façon dynamique dans VS2010
Je suis en utilisant les bibliothèques boost comme installé par le BoostPro le Calcul de l'installateur. Je suis avec VS 2010 sur un Windows 7 64-bit de la machine. Je veux le lien pour stimuler de façon dynamique, j'ai donc sélectionné les deux premières options du programme d'installation (Multithread DLL de Débogage et Multithread DLL, je crois qu'ils ont été appelés). Un exemple de quelques installé libs sont:
boost_bzip2-vc100-mt-1_51.lib
boost_bzip2-vc100-mt-gd-1_51.lib
Lors de la liaison de boost dans mon projet, j'ai également fait en sorte de définir BOOST_ALL_DYN_LINK
. Je suis plus particulièrement à l'aide de la filesystem
d'outils.
Quand j'allume BOOST_LIB_DIAGNOSTIC
je vois les messages suivants dans le construire de sortie:
1> Linking to lib file: boost_filesystem-vc100-mt-gd-1_51.lib
1> Linking to lib file: boost_system-vc100-mt-gd-1_51.lib
Toutefois, ceux-ci sont rapidement suivie par:
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const __thiscall boost::filesystem::path::string(void)const " (__imp_?string@path@filesystem@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::filesystem::path::~path(void)" (__imp_??1path@filesystem@boost@@QAE@XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::filesystem::path __cdecl boost::filesystem::detail::unique_path(class boost::filesystem::path const &,class boost::system::error_code *)" (__imp_?unique_path@detail@filesystem@boost@@YA?AVpath@23@ABV423@PAVerror_code@system@3@@Z) referenced in function "class boost::filesystem::path __cdecl boost::filesystem::unique_path(class boost::filesystem::path const &)" (?unique_path@filesystem@boost@@YA?AVpath@12@ABV312@@Z)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class std::codecvt<wchar_t,char,int> const & __cdecl boost::filesystem::path::codecvt(void)" (__imp_?codecvt@path@filesystem@boost@@SAABV?$codecvt@_WDH@std@@XZ) referenced in function "public: __thiscall boost::filesystem::path::path<char const [20]>(char const (&)[20],void *)" (??$?0$$BY0BE@$$CBD@path@filesystem@boost@@QAE@AAY0BE@$$CBDPAX@Z)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl boost::filesystem::path_traits::convert(char const *,char const *,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &,class std::codecvt<wchar_t,char,int> const &)" (__imp_?convert@path_traits@filesystem@boost@@YAXPBD0AAV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@ABV?$codecvt@_WDH@5@@Z) referenced in function "void __cdecl boost::filesystem::path_traits::dispatch<class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &,class std::codecvt<wchar_t,char,int> const &)" (??$dispatch@V?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@@path_traits@filesystem@boost@@YAXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@4@ABV?$codecvt@_WDH@4@@Z)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (__imp_?generic_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::system_category(void)" (__imp_?system_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'native_ecat''(void)" (??__Enative_ecat@system@boost@@YAXXZ)
Ne pas le auto-link.hpp
prendre soin de mon reliant pour moi? Je ne suis pas expressément demandé quelque chose lié à ce projet parce que l'auto linker semble être l'identification de tout correctement. Alors, comment est-ce que je suis absent ces choses? Aussi, elles sont déclarées comme dllimport
, et donc ne devrait pas l'éditeur de liens-être de le laisser seul et de s'attendre à être découvert au moment de l'exécution?
Merci!
Mise à JOUR: j'ai décidé de plonger dans le deuxième éditeur de liens d'erreur. C'est essentiellement disant qu'il ne peut pas trouver le destructeur pour la path
classe. Après l'exécution de dumpbin
sur le filesystem
bibliothèque, j'ai remarqué que cette ligne est dans le fichier:
??1path@filesystem@boost@@QEAA@XZ (public: __cdecl boost::filesystem::path::~path(void))
Mais de toute évidence, cela ne correspond pas avec ce que l'éditeur de liens est à la recherche d', qui est-ce:
"__declspec(dllimport) public: __thiscall boost::filesystem::path::~path(void)" (__imp_??1path@filesystem@boost@@QAE@XZ)
Avis que l'éditeur de liens est à la recherche d'une DLL version d'importation, mais la bibliothèque elle-même ne semble pas être en offrant en un seul... vous ne savez pas où aller à partir d'ici, mais il semble que l'information importante!
OriginalL'auteur aardvarkk | 2012-10-03
Vous devez vous connecter pour publier un commentaire.
En supposant que vous avez ces .lib déjà compilé, vous devez vous assurer que l' .lib fichiers sont dans le chemin de la Bibliothèque (rechercher les Répertoires VC++->chemin de la Bibliothèque).
Le compilateur va placer un lien vers la Dll au moment de la compilation, à l'aide de l' .lib pour découvrir l'entrée correcte des points etc, de sorte qu'ils peuvent être chargés de manière efficace lorsque le fichier EXE/DLL démarre au moment de l'exécution.
Le type de DLL runtime découverte vous parlez nécessite LoadLibrary + GetProcAddress type de code, qui Boost ne prend pas en charge.
(Liaison statique se met code à partir d'un statcially compilé .lib code dans votre fichier DLL/EXE.)
EDIT: Aussi, vérifiez que vous utilisez le bon .fichiers lib pour votre archicture, par exemple, 32-bits ou 64-bits. Que serait la cause d'une erreur similaire avec les signatures.
vous indiquera "machine" de type les .lib a été construit pour le (la première section de la sortie dumpbin).
Furent les .libs compilé avec Unicode, car il semble que vous êtes à la liaison d'un multi-byte character set? Si vous faites un dumpbin TOUS les sur la .lib, vous pouvez voir ce qui est exporté. Si toutes les classes sont à l'aide de wchar_t vous connaissez le problème.
Très bonne suggestion -- je vais prendre un coup d'oeil!
Hrm... la commutation du projet pour utiliser l'Unicode n'ai pas de travail... les mêmes erreurs d'édition de liens!
Une autre pensée... êtes-vous sûr que vous utilisez la version 32 bits .fichiers lib. Que serait la cause d'une erreur similaire avec les signatures.
OriginalL'auteur snowdude
Pour moi, c'était parce que le "traiter wchar_t intégrés de type" option a été défini à false, alors que
wchar_t
a été compilé en tant queunsigned short
.OriginalL'auteur Tim Sylvester
Il n'y a (à partir de votre en suspens de liste) une différence dans la convention d'appel. Ce sera la cause de la signification des symboles de ne pas correspondre. J'ai trouvé que 1.54.0 ne compilera pas toutes les bibliothèques si vous essayez de compiler avec d'autres qu' _cdecl que la convention d'appel sur Windows. Windows aime beaucoup de différentes conventions d'appel, et elles ne correspondent pas (_cdecl /Gd, __stdcall /Gz, __FASTCALL /Gr)
Aussi, au moins en 1.54.0 j'ai remarqué que certaines bibliothèques nécessitent wchar_t d'être traité comme un type intégré (Windows VS option /Zc:wchar_t) (boost::le journal de la bibliothèque pour être sûr). Ce sera également la cause en suspens erreurs comme un wchar_t ne correspond pas à court non signé dans ce cas.
OriginalL'auteur dabble53