L'éditeur de liens se lit de la bibliothèque, mais ne peut pas trouver le symbole de l'intérieur? Symbole Externe non résolu mais seulement pour Win32 et pas x64

Fond

J'ai un C astronomique de la bibliothèque que je veux utiliser dans mon application C++.

J'ai intégré dans Visual Studio 2012 Express dans les deux Win32 et x64 configurations, et:

dynamique de débogage (.dll)
dynamique de la libération (.dll)
statique debug (.lib)
statique de presse (.lib)

...c'est donc 2 * 4 = 8 total binaires (pas de comptage *.fichiers pdb, etc.)

Puis-je utiliser le traitement par Lots à Construire à construire toutes les configurations, que parfois j'ai besoin de versions différentes et je trouve que l'obtention de ce fait au début et avec un processus est mieux qu'au hasard, quand il est facile de mélanger les choses.

Bien dans mon C++ application, j'ai le même processus, et un lien vers la bibliothèque, basé sur le nom. Plus précisément, dans mon projet, propriétés de l'éditeur de liens -> Input terrain, j'ai:

SwissEphemeris_$(Platform)_$(Configuration).lib

...et la Bibliothèque Supplémentaire Répertoires est correctement défini. Tout me semble bon. La bibliothèque de fichiers sont dans le répertoire de la bibliothèque.

Voici le problème:

De l'8 total configurations que j'ai, tous sont des liens et construire correctement à l'exception de deux:

Dynamiques Win32 debug
Win32 dynamique de la libération

Pour ces deux configurations, la même erreur liens:

main.obj : error LNK2019: unresolved external symbol _swe_close referenced in function _main

J'ai essayé quelques choses à diagnostiquer ou à résoudre, mais aucun n'a travaillé:

la reconstruction de la bibliothèque à partir de zéro dans une nouvelle Solution/Projet, s'assurant de l'absence d'écart entre Win32 et x64 autre que le /MACHINE de l'éditeur de liens drapeau
la création d'une nouvelle Solution fraîche/Projet avec rien mais une main() qui appelle cela une fonction de la bibliothèque swe_close() dans Win32 dynamique configuration de débogage et *.lib.

L'erreur est toujours la même, comme indiqué ci-dessus. J'ai tourné des commentaires de l'éditeur de liens de sortie, et ce qui m'étonne vraiment, c'est que le linker semble en mesure de trouver et de lire les SwissEphemeris_Win32_DynamicDebug.lib fichier, mais ne trouvez toujours pas le swe_close() symbole. Même lorsque dumpbin.exe montre que symbole, parmi tous les autres dont j'ai besoin, sont en elle.

1>  Unused libraries:
1>    E:\Data\Code\lib\SwissEphemeris\SwissEphemeris_Win32_DynamicDebug.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\user32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\gdi32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\winspool.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\comdlg32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\advapi32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\shell32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\ole32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\oleaut32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\uuid.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\odbc32.lib
1>    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\odbccp32.lib
1>    E:\Programs\VS2012\VC\lib\OLDNAMES.lib
1>  
1>main.obj : error LNK2019: unresolved external symbol _swe_close referenced in function _main
1>E:\Data\Code\test\Debug\test.exe : fatal error LNK1120: 1 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

de vous gratter la tête

Quelqu'un a une idée de pourquoi l'éditeur de liens est de ne pas rechercher le symbole, et SEULEMENT pour les dynamiques Win32 debug/release, mais fonctionne très bien pour tous les 6 autres configurations?

Juste pour être sûr que la bibliothèque était en effet construite pour Win32/X86, ici, c'est le linker options de ligne de commande à partir de la bibliothèque de propriétés du projet:

(chemins sont légèrement différentes que les chemins d'accès ci-dessus, où l'éditeur de liens tentatives pour trouver la bibliothèque--parce que la bibliothèque est d'abord construit à ce répertoire 'bin' et de le copier dans le répertoire de la bibliothèque, qui est certainement en passe.)

/OUT:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.dll" 
/MANIFEST 
/NXCOMPAT 
/PDB:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.pdb" 
/DYNAMICBASE 
/IMPLIB:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.lib" 
/DEBUG 
/DLL 
/MACHINE:X86 
/SAFESEH 
/PGD:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.pgd" 
/SUBSYSTEM:CONSOLE 
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
/ManifestFile:"E:\Data\Code\libBuilders\SwissEphemeris\obj\SwissEphemeris_Win32_DynamicDebug\SwissEphemeris_Win32_DynamicDebug.dll.intermediate.manifest" 
/ERRORREPORT:PROMPT 
/NOLOGO

Sortie de dumpbin.exe /exports

E:\Data\Code\lib\SwissEphemeris>dumpbin /exports SwissEphemeris_Win32_DynamicDebug.dll
Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.
Dump of file SwissEphemeris_Win32_DynamicDebug.dll
File Type: DLL
Section contains the following exports for SwissEphemeris_Win32_DynamicDebug.dll
00000000 characteristics
528041A6 time date stamp Sun Nov 10 19:32:06 2013
0.00 version
1 ordinal base
131 number of functions
131 number of names
ordinal hint RVA      name
1    0 00001195 _swe_azalt@40 = @ILT+400(_swe_azalt@40)
2    1 000011FE _swe_azalt_d@28 = @ILT+505(_swe_azalt_d@28)
3    2 000012AD _swe_azalt_rev@24 = @ILT+680(_swe_azalt_rev@24)
4    3 00001357 _swe_azalt_rev_d@20 = @ILT+850(_swe_azalt_rev_d@20)
5    4 0000126C _swe_calc@24 = @ILT+615(_swe_calc@24)
6    5 000011BD _swe_calc_d@20 = @ILT+440(_swe_calc_d@20)
7    6 0000105F _swe_calc_ut@24 = @ILT+90(_swe_calc_ut@24)
8    7 00001235 _swe_calc_ut_d@20 = @ILT+560(_swe_calc_ut_d@20)
9    8 00001389 _swe_close@0 = @ILT+900(_swe_close@0)
10    9 00001212 _swe_close_d@4 = @ILT+525(_swe_close_d@4)
...

Lorsque la DLL est défini pour l'exportation dans le fichier d'en-tête de la bibliothèque. Seulement MAKE_DLL et PASCAL sont définis, de sorte que les seules instructions ici qui sont actives sont le #define PASCAL_CONV PASCAL et la #else /* 32bit DLL */ bloc.

/* DLL defines */
#ifdef MAKE_DLL
#if defined (PASCAL)
#define PASCAL_CONV PASCAL 
#else
#define PASCAL_CONV
#endif
#ifdef MAKE_DLL16 /* 16bit DLL */
/* We compiled the 16bit DLL for Windows 3.x using Borland C/C++ Ver:3.x
and the -WD or -WDE compiler switch. */
#define EXP16 __export 
#define EXP32 
#else /* 32bit DLL */
/* To export symbols in the new DLL model of Win32, Microsoft 
recommends the following approach */ 
#define EXP16 
#define EXP32  __declspec( dllexport )
#endif
#else 
#define PASCAL_CONV 
#define EXP16 
#define EXP32 
#endif

...Ensuite la fonction swe_close() déclaration ressemble à:

ext_def( void ) swe_close(void);

Ils utilisent beaucoup de macro jeu de jambes, de sorte que ce décide:

extern __declspec(dllexport) void far PASCAL swe_close();

Je suis pas familier avec le far et la PASCAL. Pourrait-on en interférant avec quoi que ce soit? Et pourquoi le x64 configuration fonctionne bien avec cela, mais le Win32 pause?

quelles sont les options que vous utilisez avec dumpbin.exe? La liste montrent que _swe_close est dans le fichier lorsque vous utilisez le /les SYMBOLES de l'option?
Bonne question. Je n'étais pas à l'aide de la /des SYMBOLES option, mais au lieu de la /des EXPORTATIONS option, qui montre le symbole. /SYMBOLES n'affiche pas le symbole swe_close() (ni beaucoup d'autres), mais quand j'ai essayé /SYMBOLES sur les autres configurations de la bibliothèque que travail, il a montré le même manque de beaucoup de symboles. /EXPORTATIONS semble montrer tous.
Il se pourrait bien que vous avez un décalage de conventions d'appel. L'éditeur de liens est d'essayer d'importer des swe_close() avec __cdecl convention d'appel (voir la section Nom de la Décoration). Est-ce conforme à la signature de l'exportation?
Merci de le signaler. Tous mes C configurations de la bibliothèque et l'ensemble de mon projet de C++ les configurations sont définies à __cdecl convention. Je ne trouve aucun mélange de convention d'appel. C'est vraiment étrange. Est-il un autre paramètre ou le drapeau que nous ne sommes pas penser à qui pourrait être le coupable? On remarque, c'est que la bibliothèque C est naturellement /TC (compiler comme code C). Peut-être que c'est évident, mais au cas où ça pourrait aider.
Je vois que votre question a été répondu. Voici un peu plus d'infos. Le jour indique que la fonction de l'adresse générée doit être une mesure ou 32 bits de l'adresse de 16 bits segment et 16 bits de décalage et de l'PASCAL indique qu'il faut utiliser la convention d'appel Pascal, plutôt que de la convention d'appel C. L'utilisation de ces indique que le colis est assez vieux. la mesure n'est plus utilisé et PASCAL tend à être utilisées avec certains appels d'API de Windows. Voir ce en.wikipedia.org/wiki/X86_calling_conventions

OriginalL'auteur nedshares | 2013-11-11

c++dll unresolved-external visual-studio-2012

6
```
 9    8 00001389 _swe_close@0 = @ILT+900(_swe_close@0)
```
Il y a clairement un décalage entre le nom de la fonction dans la DLL et celui de l'éditeur de liens est à la recherche pour. Le projet de DLL a compilé pour un __stdcall fonction, vous pouvez dire à partir de la @0 la décoration, l'éditeur de liens est à la recherche d'un __cdecl fonction.

Qui peuvent être causés par une option de compilateur /Gd vs /Gz mais c'est peu probable et que vous avez déjà vérifié. La cause plus probable est la .h de fichiers exportés fonctions sont déclarées ainsi qu'un autre projet peut #comprendre et utiliser la DLL. C'est généralement fait avec de la macro de la soupe, pour que l' __declspec(dllexport) et __ _ _ declspec(dllimport) attributs sont corrects pour l'utilisation. Et la convention d'appel doit toujours être explicitement déclaré, généralement avec une autre macro. Comme la façon dont le WINAPI macro est utilisée dans le kit de développement logiciel Windows les en-têtes. Je vais mettre de l'argent que de la soupe qui a été la cause.

Merci @HansPassant. Je vais regarder plus loin que ça. J'avais pensé qu'il pourrait être quelque chose le long de ces lignes de macros définies et ne sont pas définis dans la bibliothèque. C'est quelque chose que je suis encore à apprendre, à comprendre. J'ai trouvé une __declspec(dllexport) emplacement dans l'ensemble de la bibliothèque (dans l'en-tête principal) et collé ses environs énoncés dans le post ci-dessus si ça aide. Je suis en train d'apprendre au sujet de ces conventions de moi-même.
Je suis en train de penser sur l'extraction de l' FAR et PASCAL de l'ensemble de la bibliothèque, ou au moins les macros. Regarde ici ce qui est LOIN PASCAL?, il dit qu'ils sont de la vieille école de code qui peut être 16bit. Peut-être que je peux la modernisation de cette bibliothèque et de faire mieux pour mon usage moderne.
Il est exactement comme je l'ai deviné, PASCAL est le même que __stdcall dans le code 32 bits et votre en-tête définit incorrectement seulement quand MAKE_DLL est défini. Score un pour psychique de débogage 🙂
Juste confirmé! Enfin, mon C++ application liée correctement avec la bibliothèque de dynamiques Win32 debug/release lorsque j'ai défini PASCAL et FAR à rien. Certaines de ces bibliothèques et de code, il peut être si délicat et difficile à maintenir.

OriginalL'auteur Hans Passant

Vous devez vous connecter pour publier un commentaire.