LNK2019 due a une décoration abusive :)

Bonjour à toutes et à tous.

Lors de la compilation de mon projet, je ne rencontre aucune erreur, mais lors du linkage ...

Ma solution se décompose en deux projets :

• FreeImage : Directement téléchargé de freeimage.sourceforge.net et compilé en library statique (lib)
• Isys : créé par mes soins et utilisant une dizaines de fonctions de FreeImage (10 sur plus de mille, d'où l'utilisation de bilio statique).

Dans le main d'Isys je fais figurer

Code:

---

#pragma comment(lib, "../common/debug/FreeImage.lib")

---

Et dans son en-tête principale

Code:

---

#include "FreeImage.h"

---

Je prends bien entendu le soin de préciser à FreeImage.h qu'elle est utilisée dans le cadre d'une biblio statique (pas d'imports/exports).


Résultat :
Lors du linkage, pour chaque fonction de FreeImage que j'utilise j'obtiens l'erreur :

Code:

---

1 2	IsysSnapShot error LNK2019: symbole externe non résolu _FreeImage_Allocate référencé dans la fonction _SaveSnapshot [...]

---

J'ai donc fait une recherche dans le .lib : il apparait bien ces fonctions, mais elles sont décorées : _FreeImage_Allocate@24
Je me suis dit : et bien s'il ne s'agit que de ça, ne précisons pas à FreeImage.h que nous l'utilisons pour une lib statique, et déclarons les "__declspec(dllimport)". Résultat

Code:

---

1 2	IsysSnapShot error LNK2019: symbole externe non résolu __imp__FreeImage_Allocate@24 référencé dans la fonction _SaveSnapshot [...]

---

J'aimerais votre aide pour couper la poire en deux :)
Merci.

pour éviter la décoration, il faut utiliser extern "C"

Mais où ?
(il est déjà déclaré autour de la définitions des fonctions de FreeImage (Le FreeImage.h qui sert à la compilation du .lib & le FreeImage.h qui sert à déclarer les fonctions dans le projet Isys - en fait c'est le même fichier :))

sur la declaration du prototype de la fonction, idealement dans le .h de declaration des fonctions qui devrait etre utilisé pour la lib et pour l'application..
comme dans ce post de la faq:http://c.developpez.com/faq/vc/?page=DLL#MakeDynDll

C'est ce qui est fait. Pourtant les fonctions dans FreeImage.lib sont décorées.

Pitit up : personne a une idée pour empécher la déco ?
Merci.

bonjour

moi pour enlever la deco je cree un fichier .def quand je cree ma librairie.
A la compile les fonction ne sont plus decorées.

je les declare comme çà:

Code:

---

1 2 3

int __stdcall GetListTag(int SrPortNo,BOOL axe1,BOOL axe2,BOOL axe3,BOOL axe4,BOOL axe5,BOOL axe6); int __stdcall GetSerialPortNumber(void); int __stdcall ResetduDSP(int SrPortNo);

---

et si je veux cree une dll nomme nomdemadll.dll je cree un fichier nomdemadll.def dans mon projet qui a la forme

Code:

---

1 2 3 4 5 6 7 8 9 10 11

; GetList.def : Declares the module parameters for the DLL.   LIBRARY "GetList" DESCRIPTION 'GetList Windows Dynamic Link Library'   EXPORTS ; Explicit exports can go here   GetListTag @1 GetSerialPortNumber @2 ResetduDSP @3

---

cordialement

ricky78: pas la bonne méthode.


prgasp77, farscape, nico-pyright(c) : Les fonctions sont déjà en extern "C", mais elles sont en __stdcall dans la bibliothèque, et considérées comme en __cdecl dans le header.

Solutions:
Soit changer la convention d'appel par défaut de ton projet utilisateur (ce que je qualifierais de mauvais), soit modifier le header pour préciser que les fonctions sont en __stdcall.

PS: Apprenez à distinguer une décoration C d'une décoration C++:
Format of a C Decorated Name
Format of a C++ Decorated Name

Bonjour Médinoc.
J'ai un peu tout essayé, quand je parviens à linker les fonctions problématiques, j'ai tout le reste qui foire (environ 250 erreur de link).
Je ne sais plus trop quoi faire, est-ce ma bibliothèque qui est mal écrite ?

Edit :
Mea Culpa :(
http://freeimage.sourceforge.net/faq.html (il faut compiler spécialement la bibliothèque comme expliqué à la question How to use FreeImage as a static library instead of as a DLL (Visual C++ 6) ?).
En revanche je ne sais pas pourquoi mon linker (qui me joue encore des tours) cherche le fichier C:\Program.obj :)

Je travaille là dessus.

Tout ce qui s'appelle C:\Program est généralement un truc dans Program Files pour lequel on aurait oublié les guillemets.

Oui en effet.
Un grand merci mais ma lutte contre mon éditeur de lien n'est pas finie.

Apparemment, il ne rencontre plus de problème pour lier les fonctions de ma lib utilisée dans mon projet ... en revanche j'ai des erreurs bien étranges :

• Des symboles externes non résolus qui existent bel et bien dans le lib
• Des objets déjà défini dans FreeImage.lib (et où ailleurs ???)

Si quelqu'un a une hypothèse ... je commence à avoir des sueurs froides :piou:
Merci.


Edit :
J'ai tenté avec un programme trivial (console Win32)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include "stdafx.h" #include "FreeImage.h" #pragma comment(lib, "C:/Program Files/Microsoft Visual Studio/MyProjects/Isys/common/Release/FreeImage.lib")   int _tmain(int argc, _TCHAR* argv[]) { // fonctions du lib FreeImage_Initialise(); FreeImage_DeInitialise(); return 0; }

---

Et ces mêmes erreurs apparaissent, je me doute que le soucis vient justement de ma biblio, je tente une recompilation ... mais je n'espère plus :?

Edit 2 : Lib recompilée à l'identique ... Ouiiiiiiiiiiiinnnnnnnnnnnnnnnn
Edit 3 : J'arrive à compiler et linker en n'utilisant que des fonctions simples (FreeImage_GetVersion par exemple) ... et ça fonctionne ; mais pour la plupart des fonctions il y a plein d'erreurs commes

Code:

---

1 2

test_FreeImage_dot_lib error LNK2005: "class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl std::operator<<<struct std::char_traits<char> >(class std::basic_ostream<char,struct std::char_traits<char> > &,char const *)" (??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z) déjà défini(e) dans msvcprt.lib(MSVCP71.dll) test_FreeImage_dot_lib error LNK2019: symbole externe non résolu _TIFFWriteDirectory référencé dans la fonction "long __cdecl Save(struct FreeImageIO *,struct FIBITMAP *,void *,int,int,void *)" (?Save@@YAJPAUFreeImageIO@@PAUFIBITMAP@@PAXHH2@Z)

---

La première erreur semble indiquer que quelque chose tente de redéfinir l'opérateur d'insertion d'un const char * dans un ostream.

L'autre indique qu'il ne trouve pas une fonction extern "C" __cdecl, dont une fonction C++ a besoin.