2010-12-06 35 views
0

Je suis en train de créer une solution dans Visual C++ où j'ai un projet frontal qui référence un projet DLL que j'ai créé. Dans le projet DLL, je lie à une bibliothèque statique (que je n'ai pas écrite) qui a des objets statiques et des définitions. Tout se construit bien mais j'ai des problèmes de liaison.Utilisation d'une DLL qui lie à une bibliothèque statique

J'ai quelques questions. Tout d'abord, je ne devrais obtenir que des symboles non résolus pour les objets que je référence dans le front-end qui ne sont pas exportés, n'est-ce pas? Je veux que la DLL soit la seule interface à la bibliothèque statique et ne fasse directement référence à aucune partie de celle-ci dans le frontal, et pourtant j'obtiens un certain nombre de symboles non résolus de cette bibliothèque. Les symboles semblent #include et au moins certains ne sont pas directement liés par le projet DLL. Je soupçonne que cela a à voir avec les déclarations statiques dans la bibliothèque statique, mais comment puis-je faire face à ces déclarations?

Certaines des erreurs de symboles non résolus:

2>AnalysisVis.obj : error LNK2001: unresolved external symbol "public: __thiscall SharkException::SharkException(char const *,int,char const *)" ([email protected]@[email protected]@Z) 
2>AnalysisVis.obj : error LNK2001: unresolved external symbol "public: static class Bernoulli Rng::coinToss" ([email protected]@@[email protected]@A) 
2>AnalysisVis.obj : error LNK2001: unresolved external symbol "public: virtual bool __thiscall ChromosomeT<bool>::operator<(class Chromosome const &)const " ([email protected][email protected]@[email protected]@@Z) 
+0

Quel est le point dans l'utilisation d'une DLL en tant qu'interface à une bibliothèque statique? S'il vous plaît, expliquez! – TonyK

+0

La DLL n'est pas seulement une interface avec la bibliothèque statique, elle possède sa propre fonctionnalité mais elle utilise la bibliothèque statique. – Nigel

+0

duplication possible de [code d'initialisation de variable statique jamais appelé] (http://stackoverflow.com/questions/1897184/static-variable-initialisation-code-never-gets-called) –

Répondre

0

Les symboles exportés sont mutilées. Si la bibliothèque statique a été compilée en utilisant un compilateur différent (ou une version du compilateur) différent de celui que vous utilisez, il est possible que les symboles que votre application s'attend à voir aient été définis dans la bibliothèque statique en utilisant un schéma différent. Vous pouvez utiliser la commande suivante pour obtenir le nom mangling utilisé dans le répertoire lib statique puis le comparer à celui du message d'erreur:

>pushd <path_to_msvc_dir>\Microsoft Visual Studio X.0\VC\bin 
>dumpbin /all [static_lib_path] > out.txt 
>type out.txt | find /I "SharkException" 
>type out.txt | find /I "coinToss" 
>type out.txt | find /I "ChromosomeT" 

BTW, est-ce la DLL qui utilise la lib statique compile proprement avec le même compilateur votre application/solution fait?

+0

Oui, le projet DLL fait partie de la même solution que l'application et il compile d'abord proprement. – Nigel

+0

Aussi, j'ai essayé de faire ce que vous avez suggéré et je trouve ce qui suit dans la lib statique: AD? 0SharkException @@ QAE @ PBDH0 @ Z, C9BCC4? CoinToss @ Rng @@ 2VBernoulli @@ A, mais je ne trouve pas le symbole ChromosomeT Là. Pourquoi tous les trois apparaissent alors? Et que puis-je faire à propos de ce nom mangling? – Nigel

+0

Les symboles apparaissent dans la bibliothèque parce qu'ils y ont été définis. Je suppose que les fonctions exportées de votre DLL utilisent ces symboles mais ne les exportent pas - d'où votre problème. L'interface dll peut utiliser ces symboles indirectement via des objets définis par DLL qui en dépendent, ce qui peut être difficile à localiser. Si votre dll se compile proprement alors le mangling n'est probablement pas un problème. Pouvez-vous commencer à supprimer des éléments de votre interface DLL afin de découvrir quel est l'objet incriminé? Une fois que vous l'avez trouvé, vous pouvez le remplacer par un objet DLL pur et vous devriez être OK. – hillel