Discussion :

[Anais.serguier]

Bonjour tout le monde !

Alors voici ce que j'essaye de faire (comme dit dans le titre) :

Créer une DLL et dans cette DLL j'utilise des fonctions mise à disposition par une autre dll.
Mais voilà lors de la compilation de mon projet j'ai ce message : erreur LNK2019 symbole externe non résolu.
Et en fait je me suis rendue compte que toutes les fonctions que provenant de l'autre dll, lorsque je fais go to declaration, sont soulignées de vert et que leur définition est introuvable.

Mais voilà, j'ai bien renseigné dans les propriétés du projet > répertoires VC++,
le path pour le répertoires d'include correspondant au dossier ou il y a les fichiers .h de l'autre dll
le path pour le répertoire de bibliothèque correspondant au dossier ou il y a les fichiers .dll et .lib de l'autre dll

Dans Editeur de liens > entrée > dépendances supplémentaires j'ai rajouté le .lib de l'autre dll

J'ai bien vérifié dans le fichier .def on retrouve bien les fonctions de l'autre dll que j'essaye d'utiliser

Donc je ne comprends pas pourquoi, il ne trouve pas leur définition..

Je suis preneuse de toutes idées !
Merci

[bacelar]

Vous semblez ne pas avoir raté d'étapes dans l'utilisation d'une Dll par lien "statique".
Pouvez-vous nous donnez les premiers messages d'erreur et le début et la fin du fichier d'en-tête de la Dll ?

[Anais.serguier]

Voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
1>Client.obj : error LNK2019: symbole externe non résolu "enum ReturnStatus __cdecl String_CopyFromCString(struct String *,char const *)" (?String_CopyFromCString@@YA?AW4ReturnStatus@@PEAUString@@PEBD@Z) référencé dans la fonction "public: int __cdecl Client::Read(int,char *,int,int,int)" (?Read@Client@@QEAAHHPEADHHH@Z)
1>Client.obj : error LNK2019: symbole externe non résolu "void __cdecl Sleep(unsigned int)" (?Sleep@@YAXI@Z) référencé dans la fonction "public: enum ReturnStatus __cdecl Client::InitializeSession(struct SecureChannel_Config)" (?InitializeSession@Client@@QEAA?AW4ReturnStatus@@USecureChannel_Config@@@Z)
1>Client.obj : error LNK2019: symbole externe non résolu "void __cdecl ToolkitClient_AsyncActivateSession(unsigned int)" (?ToolkitClient_AsyncActivateSession@@YAXI@Z) référencé dans la fonction "public: enum ReturnStatus __cdecl Client::InitializeSession(struct SecureChannel_Config)" (?InitializeSession@Client@@QEAA?AW4ReturnStatus@@USecureChannel_Config@@@Z)

...


Et pour ce qu'y est de l'entête et de la fin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#pragma once
#ifndef WRAPPERAPI_H
#define WRAPPERAPI_H
 
 
extern "C" __declspec(dllexport) int __stdcall Initialize()
 
...
 
#endif

Est ce bien ça que vous attendiez ?

Merci pour votre aide !

[bacelar]

Il a une salle tête votre .h, vous êtes sûr que c'est le .h pour le code utilisateur de la Dll ???
Généralement, ce genre de .h import des symboles, ici "__declspec(dllexport)" ça exporte.

Les messages d'erreurs indiquent que l'éditeur de lien cherche des fonctions avec des noms "décorés" à la C++, c'est assez rare car ce n'est pas portable entre compilateurs.
On préfère exporter les fonctions avec des conventions nommage C plutôt que C++ car c'est portable entre compilateurs. C'est le rôle des 'extern "C" {...}'.

Vérifiez le nom des fonctions exportés par votre Dll avec un outil comme Dependency Walker (http://www.dependencywalker.com/).

Si c'est des noms à la C, il faudrait vraisemblablement entourer le #include du .h de la Dll par 'extern "C" {...}'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
extern "C" {
#include "WRAPPERAPI.H"
}

Mais votre .h me semble pas très catholique.
On peut l'avoir en entier ?

[Anais.serguier]

Oui alors les dllexport dans ce fichier .h c'est pour exporter les fonctions qui seront accessibles par cette nouvelle dll pour créer une appli par exemple.
Mais effectivement, il me manque bien également les dllimport...

J'ai donc construit un nouveau fichier .h, je rajoute les fonctions comme tel

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

extern "C" __declspec(dllimport) ReturnStatus __cdecl StringCopyFromCString (struct String* chaine1, char const* chaine2);

avec en plus les définitions des types comme ReturnStatus, etc.
Mais ça me fait beaucoup trop de définitions à déclarer...

J'ai donc essayé de rajouter extern "C" __declspec(dllimport) devant ma fonction directement dans le fichier .h où y'a la fonction issu de ma dll, mais ça ne fonctionne pas également.

A chaque fois, j'ai de nouveau le petit soulignage vert "La définition de fonction est introuvable".

De quoi ça viendrait ?

Car j'ai déjà réalisé un travail similaire, et je n'avais pas eu besoin de faire un dllimport mais si j'ai bien suivi c'est parce que ma dll de base était compilé en VC++ et là elle est compilée en CLang.

Les messages d'erreurs indiquent que l'éditeur de lien cherche des fonctions avec des noms "décorés" à la C++, c'est assez rare car ce n'est pas portable entre compilateurs.
On préfère exporter les fonctions avec des conventions nommage C plutôt que C++ car c'est portable entre compilateurs. C'est le rôle des 'extern "C" {...}'.

Vérifiez le nom des fonctions exportés par votre Dll avec un outil comme Dependency Walker (http://www.dependencywalker.com/).

Si c'est des noms à la C, il faudrait vraisemblablement entourer le #include du .h de la Dll par 'extern "C" {...}'

Alors je ne suis pas sûre d'avoir bien compris, des noms "décorés" c'est à dire ?
car je crois bien que la dll de base est bien construite en C, et moi je travaille en C++ sur la nouvelle DLL

J'ai utilisé Dependency Walker pour voir si les fonctions étaient bien exportées par la dll de base, mais ça n'indiqué que leur nom par les arguments fournis ni ceux retournés.

[Anais.serguier]

Ok, après avoir relu votre réponse plus attentivement, en effet en encadrant mes #include par extern "C" {} je suis arrivée à compiler !

Merci beaucoup !!