Problème d'édition de lien avec Visual Studio 2013

Salut à tous

J'avais un projet qui fonctionnait sous visual studio 2005 et je suis passé à la version 2013.
Maintenant quand je le compile il me met des erreurs d'édition de lien

Code:

---

error LNK2019: symbole externe non résolu "public: __thiscall CLogPalette::CLogPalette(unsigned short,int,class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > >)" (??0CLogPalette@@QAE@GHV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z) référencé dans la fonction "protected: virtual int __thiscall CMINDEF_INTEL2013Dlg::OnInitDialog(void)" (?OnInitDialog@CMINDEF_INTEL2013Dlg@@MAEHXZ)

---

J'ai pourtant renseigné les champs

• Dépendance additionnelles avec les noms de mes bibliothèques
• Répertoires supplémentaires des bibliothèques

Y a t'il moyen de savoir où il a cherché les bibliothèque lors de l'édition de lien?

Commencez par vérifier que la librairie exporte bien "??0CLogPalette@@QAE@GHV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z" en utilisant dumpbin.

Elle l'exporte forcément puisque ça fonctionnait avec visual studio 2005 et que les bibliothèque n'ont pas changé.
Ceci dit par acquis de conscience j'ai fait un dumpbin Tools.dll /Export et le résultat et le suivant
76 4B 00028300 ??0CLogPalette@@QAE@GHV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z

Bingo!
undname.exe ??0CLogPalette@@QAE@GHV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z

donne "public: __thiscall CLogPalette::CLogPalette(unsigned short,int,class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > >)"

undname.exe ??0CLogPalette@@QAE@GHV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z

donne "public: __thiscall CLogPalette::CLogPalette(unsigned short,int,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >)"

Vous cherchez (le linker) la version UNICODE de ATL::CStringT utilisant les MFC (avec une C-Runtime en librairie statique vraisemblablement) et dans la librairie, c'est une version ASCII utilisant la C-Runtime en Dll qu'on trouve.

C'est pas pareil :mrgreen:.

Ok mais comment puis je corriger le problème?
je suis chez moi et je n'ai pas le code sous la main mais de mémoire il s'agit de la déclaration du constructeur de la classe CLogPalette
qui est:

Code:

---

public CLogPalette(DWORD Palette, BOOL var, CString Nom)

---

Le problème, c'est "CString Nom".
J'espérais plus un "const CString& Nom" pour éviter des copies inutiles, mais bon.

CString est une classe à géométrie variable en fonction des constantes de compilations.

Votre projet, qui ne link pas, interprète "CString" comme égale à "ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > >", en gros, une string UNICODE (because wchar_t), avec une API à la MFC (because StrTraitMFC).
Pour votre librairie "CString" est égale à "ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >", en gros, une string ASCII(because char), avec une API à la MFC (because StrTraitMFC) et le _DLL, faudrait voir dans les includes si c'est lié à la version Dll/static des MFC ou de la C-Runtime.


Pour que cela marche, il faut que votre programme et votre librairie ait la même définition de "CString", il faut donc pour cela que les options de compilations de votre programme et votre librairie soient les mêmes, au moins sur le choix UNICODE/ASCII, MFC/pasMFC, MFC en Dll/en static et C-Runtime en Dll/en static.

Si c'est une librairie "du commerce", il y a de grosse chance que vous utilisiez la mauvaise version de la librairie car, si elle exporte des CString aussi salement, elle devrait fournir une version différente pour que interprétation possible de CString.

Citation:

---

Envoyé par bacelar

Pour que cela marche, il faut que votre programme et votre librairie ait la même définition de "CString", il faut donc pour cela que les options de compilations de votre programme et votre librairie soient les mêmes, au moins sur le choix UNICODE/ASCII, MFC/pasMFC, MFC en Dll/en static et C-Runtime en Dll/en static.

---

Dans mon projet il y a 2 DLL l'une est commerciale et je n'ai pas le source. L'autre figure dans les exemples de code et j'ai le source.
Dans mon projet j'ai mis le jeu de caractère à Multi-Byte Caracter Set et j'ai vu que le projet avait avait l'option Use MFC à Use MFC in static library tandis que la DLL (donnée dans l'exemple) avait l'option Use MFC à Use MFC as a shared DLL du coup j'ai tout mis à Use MFC as a shared DLL.
Ça a corrigé l'erreur d'édition de lien avec la DLL commerciale.

Par contre j'en ai encore 2 erreur sur la DLL exemple qui sont lié à aux CString

Code:

---

1 2	BOOL AllocSharedMemory (DWORD dwSizeByte, CString & strSharedName, HANDLE & hSharedMem, void *& pMemBuffer);

---

Erreur->protected: int __thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > &,void * &,void * &)" (?AllocSharedMemory@CVCamClient@@IAEHKAAV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@AAPAX1@Z)

Code:

---

1 2	BOOL InitializeVCam(ULONG nVersionMajorMinimum, ULONG nVersionMinorMinimum, ULONG nVersionBuildMinimum, BOOL bAutomaticConnection, BOOL bShowSpy, BOOL bInitImage, CString & strError);

---

Erreur->protected: int __thiscall CVCamClient::InitializeVCam(unsigned long,unsigned long,unsigned long,int,int,int,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > &)" (?InitializeVCam@CVCamClient@@IAEHKKKHHHAAV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z)


Je pense avoir passé en revue la plus part des options des deux projets pour vérifier qu'elles sont identiques et ça coince toujours

Pour ce qui est des include je n'ai rien vu de particulier.

L'option Use MFC est à Use MFC as a shared DLL
la runtime library est Multithreaded DLL

J'ai fait l'expérience suivante:
j'ai copié ce code qui est dans mon projet et qui fait appel à la DLL commerciale dans la DLL exemple

Code:

---

1 2	m_pPalette = new CLogPalette(PALETTE_GREY,FALSE);

---

J'ai une erreur d'édition de lien lors de la compilation de la DLL exemple alors que ce n'est plus le cas avec le projet
J'ai du mal à voir ce qui pose problème

Vous aviez donc un problème d'alignement des options de compilation entre votre exécutable et votre DLL commerciale, et maintenant c'est bon.

Vous avez maintenant juste un problème d'alignement entre votre Dll "exemple" et le reste.
On va donc utiliser la même méthode :
Voir avec dumpbin ce qu'export le fichier lib de votre dll d'exemple.
Et jouer au jeu des 7 erreurs entre ce que le linker veux voir (dans le message d'erreur) et ce que la lib exporte (dans la sortie de dumpbin).

Voici ce que donne dumpbin pour la méthode
BOOL AllocSharedMemory (DWORD dwSizeByte, CString & strSharedName, HANDLE & hSharedMem, void *& pMemBuffer);

182 00053AE0 ?AllocSharedMemory@@YAHKAAV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@AAPAX1@Z

undname donne

182 00053AE0 int __cdecl AllocSharedMemory(unsigned long,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > &,void * &,void * &)

et pour l'autre méthode
BOOL InitializeVCam(ULONG nVersionMajorMinimum, ULONG nVersionMinorMinimum, ULONG nVersionBuildMinimum, BOOL bAutomaticConnection, BOOL bShowSpy, BOOL bInitImage, CString & strError);

6 00003670 ?InitializeVCam@CVCamClient@@IAEHKKKHHHAAV?$CStringT@_WV?$StrTraitMFC_DLL@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z

undname donne

6 00003670 protected: int __thiscall CVCamClient::InitializeVCam(unsigned long,unsigned long,unsigned long,int,int,int,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &)

Sinon j'ai trouvé une solution qui a consisté à extraire les méthode qui m'intéresse de la DLL exemple pour les intégrer à mon projet. Ça fonctionne mais je ne sais pas pourquoi et c'est un peu gênant surtout que je ne peut pas actuellement tester complètement mon projet (mon projet pilote une caméra qui n'est pas disponible actuellement donc je ne peux aller que jusqu'à la génération du code sans l'exécuter)

protected: int __thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > &,void * &,void * &)"
C'est plus :

Code:

---

1 2 3 4 5 6 7 8

class CVCamClient { ... protected: ... int AllocSharedMemory((DWORD dwSizeByte, CString & strSharedName, HANDLE & hSharedMem, void *& pMemBuffer); ... };

---

que

Code:

---

BOOL AllocSharedMemory (DWORD dwSizeByte, CString & strSharedName, HANDLE & hSharedMem, void *& pMemBuffer);

---

L'une est une méthode de la classe CVCamClient et l'autre est une fonction "libre".

Vous cherchez une méthode de CVCamClient mais vous avez trouvé la fonction, si dumpbin n'affiche pas la METHODE comme symbole exporté par votre lib, c'est normal que le compilateur gueule.
Pour que le compilateur est accepté ce genre de truc, il doit avoir un truc qui sent pas bon dans les .h utilisés par le projet.


Cherché :
protected: int __thiscall CVCamClient::InitializeVCam(unsigned long,unsigned long,unsigned long,int,int,int,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > &)
Trouvé :
protected: int __thiscall CVCamClient::InitializeVCam(unsigned long,unsigned long,unsigned long,int,int,int,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &)

Le linker cherche la version ASCII et votre lib exporte une version UNICODE. Faut choisir. :mrgreen:

Je confirme que AllocSharedMemory est une méthode de CVCamClient et non une fontion libre je me suis peut être mélangé les pinceaux quand j'ai extrait les résultats de dumpbin

Ce résultat doit mieux aller

3 00002530 ?AllocSharedMemory@CVCamClient@@IAEHKAAV?$CStringT@_WV?$StrTraitMFC_DLL@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@AAPAX1@Z
undname
3 00002530 protected: int __thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &,void * &,void * &)

Citation:

---

Le linker cherche la version ASCII et votre lib exporte une version UNICODE. Faut choisir.

---

Je suis bien d'accord et il m'avait semblé que j'avais choisi la même chose pour les deux. J'ai balayé toutes les propriétés des deux projets et elles sont identiques. Maintenant j'ai peut être loupé quelque chose

Ok, on se retrouve avec le même problème pour les 2 méthodes.
Le réglage dans les propriétés du projet est global au projet.
Ce réglage peut très facilement être redéfini dans les sources.

Le plus direct est de voir pourquoi le compilateur interprète le CString dans le .h de la classe CVCamClient en "char" et non en "wchar_t".
En utilisant l'option /P (http://msdn.microsoft.com/en-us/library/8z9z0bx6.aspx) sur le ou les fichiers qui appel ces méthodes.
Cela génère un .i avec le résultat du préprocesseur et donc après la résolution des "define".
Vous devriez trouver les raisons de cette erreur dans ce ou ces fichiers .i.

J'ai bien mis l'option /P sur le fichier .cpp de mon projet mais il doit manquer quelque chose car il me met l'erreur suivante
fatal error LNK1104: impossible d'ouvrir le fichier 'Debug\PILOTAGECAM2013Dlg.obj'
et je n'ai pas de .i généré

Le message d'erreur du linker est normal, l'option /P arrête le processus de compilation du cpp avec la génération du .obj.
Il vaut mieux compiler juste le .cpp que tout le projet.
Le .i doit être dans l'arborescence du projet, quelque part avec les fichiers sources ou temporaires.

C'est bon je l'ai trouvé par contre que faut il chercher dedans

Bin, là, faut se mettre dans les bottes du compilateur et donc comprendre pourquoi il veut du "char" et non du "wchar_t".

Vous devriez avec dans ce .i le define de CString, qui est faux.
En fonction de l'endroit (dans quel .h, qui sont indiqué dans le .i) de ce define foireux, vous devriez voir quelle constante de compilation a la mauvaise valeur.
Le .i indiquera aussi l'endroit où la valeur de la constante de compilation erronée est mal initialisée.

A la fin, c'est juste la bonne constante de compilation ou un #define merdeux à corriger.

Voici ce que je trouve

Code:

---

1 2 3 4 5 6 7

#line 94 "c:\\program files (x86)\\microsoft visual studio 12.0\\vc\\atlmfc\\include\\afxstr.h" #line 96 "c:\\program files (x86)\\microsoft visual studio 12.0\\vc\\atlmfc\\include\\afxstr.h"   typedef ATL::CStringT< wchar_t, StrTraitMFC_DLL< wchar_t > > CStringW; typedef ATL::CStringT< char, StrTraitMFC_DLL< char > > CStringA; typedef ATL::CStringT< TCHAR, StrTraitMFC_DLL< TCHAR > > CString;

---

Est ce que le problème ne viendrait pas du contenu des stdafx.h
Voici celui de PILOTAGECAM2013

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

// stdafx.h*: fichier Include pour les fichiers Include système standard, // ou les fichiers Include spécifiques aux projets qui sont utilisés fréquemment, // et sont rarement modifiés   #pragma once   #ifndef VC_EXTRALEAN #define VC_EXTRALEAN // Exclure les en-têtes Windows rarement utilisés #endif   #include "targetver.h"   #define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // certains constructeurs CString seront explicites   // désactive le masquage MFC de certains messages d'avertissement courants et par ailleurs souvent ignorés #define _AFX_ALL_WARNINGS   #include <afxwin.h> // composants MFC principaux et standard #include <afxext.h> // extensions MFC           #ifndef _AFX_NO_OLE_SUPPORT #include <afxdtctl.h> // Prise en charge MFC pour les contrôles communs Internet Explorer*4 #endif #ifndef _AFX_NO_AFXCMN_SUPPORT #include <afxcmn.h> // Prise en charge des MFC pour les contrôles communs Windows #endif // _AFX_NO_AFXCMN_SUPPORT   #include <afxcontrolbars.h> // prise en charge des MFC pour les rubans et les barres de contrôles   #ifdef _UNICODE #if defined _M_IX86 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"") #elif defined _M_X64 #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"") #else #pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"") #endif #endif

---

et celui de la DLL

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

// stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // are changed infrequently   #pragma once   #ifndef VC_EXTRALEAN #define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers #endif   #define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit   #include <afxwin.h> // MFC core and standard components #include <afxext.h> // MFC extensions   #ifndef _AFX_NO_OLE_SUPPORT #include <afxole.h> // MFC OLE classes #include <afxodlgs.h> // MFC OLE dialog classes #include <afxdisp.h> // MFC Automation classes #endif // _AFX_NO_OLE_SUPPORT   #ifndef _AFX_NO_DB_SUPPORT #include <afxdb.h> // MFC ODBC database classes #endif // _AFX_NO_DB_SUPPORT   #ifndef _AFX_NO_DAO_SUPPORT #include <afxdao.h> // MFC DAO database classes #endif // _AFX_NO_DAO_SUPPORT   #include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls #ifndef _AFX_NO_AFXCMN_SUPPORT #include <afxcmn.h> // MFC support for Windows Common Controls #endif // _AFX_NO_AFXCMN_SUPPORT

---

Si vous commencez à faire des hypothèses et que vous essayez de les étaillées après, vous allez jamais arriver au bout.

Moi, je fais dans le bête et méchant.

Sommes-nous d'accord que le programme cherche :
protected: int __thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > &,void * &,void * &)

Mais qu'il devrait cherché :
__thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &,void * &,void * &)

OK ?

Je commence par chercher dans le .i, la déclaration de la méthode "AllocSharedMemory" dans la déclaration de la class CVCamClient, histoire de voir si des MACRO n'ont pas piégés cette déclaration.
Si c'est bien un CString qui est déclaré comme 2ème arguments, vous vérifiez, toujours dans le .i, la définition de CString.
A en croire le premier extrait de code de votre dernier post :

Code:

---

typedef ATL::CStringT< TCHAR, StrTraitMFC_DLL< TCHAR > > CString;

---

Il faut donc voir, dans le .i, comment est défini "TCHAR".
Et si je ne suis pas trop à la masse, vous devriez avoir un truc comme :

Code:

---

#define TCHAR char

---

Ce qui ne devrait pas être le cas si vous avez bien mis UNICODE dans les constantes de compilation de votre projet.
Il faut donc vérifier les #ifdef qui entoure cette déclaration de TCHAR pour voir quelle constante de compilation ou #define dans un .h est faux.

Citation:

---

Envoyé par bacelar

Je commence par chercher dans le .i, la déclaration de la méthode "AllocSharedMemory" dans la déclaration de la class CVCamClient, histoire de voir si des MACRO n'ont pas piégés cette déclaration.

---

Voici ce que j'ai trouvé

Code:

---

1 2	BOOL AllocSharedMemory (DWORD dwSizeByte, CString & strSharedName, HANDLE & hSharedMem, void *& pMemBuffer);

---

Citation:

---

Envoyé par bacelar

Si c'est bien un CString qui est déclaré comme 2ème arguments, vous vérifiez, toujours dans le .i, la définition de CString.
A en croire le premier extrait de code de votre dernier post :

Code:

---

typedef ATL::CStringT< TCHAR, StrTraitMFC_DLL< TCHAR > > CString;

---

Il faut donc voir, dans le .i, comment est défini "TCHAR".
Et si je ne suis pas trop à la masse, vous devriez avoir un truc comme :

Code:

---

#define TCHAR char

---

---

C'est bien ça et le TCHAR est défini comme suit dans la DLL:

Code:

---

1 2	typedef char TCHAR, *PTCHAR;

---

Mais il est définit exactement de la même manière dans le projet PILOTAGECAM2013 :aie:
C'est pour ça que j'ai posté lest stdafx car je pensais que la différence aurait pu se trouver là.

Je suis perdu :
PILOTAGECAM2013 ? C'est quoi, l'exécutable final ??
dans la DLL ??? quelle Dll, la commerciale ou la "Dll exemple" ???
"__thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &,void * &,void * &)" est exporté par la Dll commerciale ou la Dll "exemple" ???

Faut juste que le linker qui link le module ( qui ne link pas because erreur de link) cherche le symbole correspondant au symbole exporté par la librairie passée en paramètre au linker.

Si la librairie exporte en wchar_t, il faut que le module "client" de la lib cherche en wchar_t.

Alors, on commence par le début, vous faites un exécutable UNICODE ou ASCII ???

Citation:

---

Envoyé par bacelar

Je suis perdu :
PILOTAGECAM2013 ? C'est quoi, l'exécutable final ??

---

Oui

Citation:

---

Envoyé par bacelar

dans la DLL ??? quelle Dll, la commerciale ou la "Dll exemple" ???

---

Le DLL exemple

Citation:

---

Envoyé par bacelar

"__thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &,void * &,void * &)" est exporté par la Dll commerciale ou la Dll "exemple" ???

---

Par la DLL exemple

Citation:

---

Envoyé par bacelar

Alors, on commence par le début, vous faites un exécutable UNICODE ou ASCII ???

---

J'arrive à utiliser la DLL commerciale si je suis en ASCII (ou en multi-Byte character) mais pas en UNICODE
Donc j'ai changé les paramètre de l’exécutable final et de la DLL exemple pour qu'ils utilisent le multi-Byte character

Si votre Dll exemple exporte "__thiscall CVCamClient::AllocSharedMemory(unsigned long,class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &,void * &,void * &)" en étant compilée en ASCII, c'est très étrange ?
C'est quoi la définition de cette méthode dans le .h de la Dll d'exemple ?
C'est quoi la signature de cette méthode dans le .cpp de la Dll d'exemple ?
Le résultat de la "compilation" de ce fichier .cpp est-il conforme au résultat du dumpbin ?

Moi aussi j'ai beaucoup de mal à comprendre ce qui ce passe. Je me vois contraint de suspendre notre conversation car je suis en déplacement pour 2 semaines et je ne pourrais pas me pencher sur le problème.
Je vous remercie énormément pour l'aide et le temps passé, j'ai beaucoup appris avec vous.