Erreur linker incompréhensible MSVC

Bonjour à tous,

Alors voila, je viens vous voir car je ne comprends pas une erreur de lien dans VS Express.

Je fait un simple appel à Connect d'une librairie dans le main. J'inclus donc le fichier MaLib.h, j'ajoute la librairie (statique) dans les options du Linker, et je compile, en me disant que tout devrait bien ce passer.
Or je recois :

Code:

---

error LNK2019: symbole externe non résolu _Connect référencé dans la fonction...

---

Donc la je vais vérifier ma librairie et la table des symbole, et la je trouve bien ma fonction _Connect avec le symbole T. Donc elle est bien définie. La librairie est bien trouvée par VS puisque je n'ai pas d'erreur d'IO.

Je ne comprends donc pas pourquoi VS ne trouve pas ma fonction.

Nouvelle tentative avec le .obj fournit avec la bibliothèque, la fonction est bien présente dans la table des symboles, je lie le .obj dans le linker de VS. Et bien même erreur...

Je ne suis pas expert mais je connais quand même les grands principes de la compilation et de l'édition des liens. J'avoue que la j'ai besoin de vos lumières car il s'agit surement d'une astuce.

Merci

Bonjour,

pour pouvoir t'aider, il nous faudrait un peu plus de détails. Le message d'erreur en entier serait un bon début :)

Hello,

A tu vérifié que le path de ta lib est inclus dans les paramètres de ton projet?

tools->options->project and solutions->VC++ directories -> library files


+++

François

Bonjour,

Merci de vous interesser au sujet.

Pour le message d'erreur le voici. Rien de très inhabituel je pense. Une erreur de lien qui se résout assez simplement d'habitude :

Code:

---

Tests_Api.obj : error LNK2019: symbole externe non résolu _Connect référencé dans la fonction "void __cdecl test(void)" (?test@@YAXXZ)

---

PS : je passe par une fonction intermédiaire void test(void)

@trop_wizz
La librairie est dans le répertoire du projet donc à priori aucun soucis de ce coté la. Quand j'enleve la librairie du répertoire, il me met une erreur de ilbrairie introuvable (normale), ce qui me fait dire que s'il ne met pas ce genre d'erreur c'est qu'il la trouve.

Dernière question au passage : quel est l'intéret d'un .obj ? correspond t-il aux .o de compils sous gcc ?

Il y a quelque chose qui me chiffonne dans ce message d'erreur, c'est le underscore avant Connect: _Connect
Apparemment il cherche la fonction _Connect(), et non Connect()

Sinon, cette fonction appartient à une classe ou est-ce une fonction libre?

Citation:

---

Envoyé par PsyKo BoY

Dernière question au passage : quel est l'intéret d'un .obj ? correspond t-il aux .o de compils sous gcc ?

---

Oui c'est à peu près pareil que les .o sous linux. Il y a un .obj (ou .o) pour chaque classe de ton projet. Ils correspondent au résultat compilé de ces classes.
Mais dans ton cas, tu ne devrais pas avoir à t'intéresser au .obj.
En fait, on ne doit jamais avoir besoin de s'y intéresser (normalement).

Ok, merci

Moi aussi le underscore me chiffone mais il me semble que c'est normal. Je l'ai eu à chaque fois que j'ai compilé une librairie. Don je ne pense pas que le problème vienne de la.

J'ai tenté autre chose :

En utilisant le .obj, j'obtiens du mieux : à la place d'utiliser la librairie que j'ai faitn j'utilise le .obj (nommé api.obj) fournit par l'API, j'obtiens le message :

Code:

---

api.obj : error LNK2019: symbole externe non résolu _GetErrorString@0 référencé dans la fonction _Connect@4

---

Ca veux dire que quelque part il trouve ma fonction Connect non ?
Le message d'erreur ci dessus n'est pas un problème. Il se résout en ajoutant le lien vers le .obj qui définit cette fonction "GetErrorString").

Pourtant à la même compil, je recois quand meme :

Code:

---

1>Tests_Api.obj : error LNK2019: symbole externe non résolu _Connect référencé dans la fonction "void __cdecl test(void)" (?test@@YAXXZ)

---

Donc je ne comprends pas trop, comment il peut trouver des symboles non résolus dans une fonction, pour laquelle il n'arrive pas à résoudre les liens ?
Cela peut il venir du @4 apres le nom de la fonction (qui reste pour moi un mystère)

Je te conseillerai de laisser tomber cette histoire de .obj. C'est la "cuisine interne" du compilateur, et en tant que développeur il vaut mieux ne pas s'en occuper. En tout ca, en 10 ans de dev intensif en c++, je n'ai jamais eu à y mettre les mains.

Quelle est cette lib externe que tu utilises? Il y a de la doc?
J'ai l'impression que cette lib utilise une dépendance "non linkée", et qu'il te faut l'ajouter à ton projet.

Ouais je pense aussi que bidouiller avec les obj ne sert pas à grand chose, si ce n'est faire le link à la main.
C'est une api propriétaire d'un client. Pas de doc ni rien...donc c'est pas simple.

Je suis en train de chercher un peu, mais je pense que je vais devoir pousser pour qu'on me donne une version propre si elle existe...

Hisoire d'en avoir le coeur net: tu n'as pas d'erreur à la compilation?

A part cette erreur de symbole non résolu, je n'ai rien...

Au fait, l'utilisation du #pragma pour lier une lib revient au meme que de la rajouter dans les dépendances additionnelles ? Je ne sait pas si l'utilisation d'un #pragma pourrait changer quelque chose à un import "classique"

Citation:

---

Envoyé par PsyKo BoY

Au fait, l'utilisation du #pragma pour lier une lib revient au meme que de la rajouter dans les dépendances additionnelles ? Je ne sait pas si l'utilisation d'un #pragma pourrait changer quelque chose à un import "classique"

---

pragma fait la même chose que de la rajouter dans les dépendances du projet. C'est un mot-clé spécifique à ms visual studio, et n'est donc pas trop conseillé.

C'est bien ce qu'il me semblait ! Merci encore pour ton aide r0d !

Si j'étais toi, ce que je ferais, c'est un projet minimal qui reproduit l'erreur avec visual express. Tu leurs envoies ce projet (en plus visual express est gratuit et téléchargeable) avec le message d'erreur (en entier), et en attendant, tu chope le dernier draft du c++0x11 et tu le lis.

Nan mais sérieusement, c'est idiot de perdre du temps sur des bêtises pareilles, vu qu'apparemment tu n'y es pour rien.