Discussion :

[Anais.serguier]

Bonjour

Je vous explique mon problème, auquel je ne trouve pas la solution ailleurs...
J'ai un projet sous Visual Studio, utilisant des dll d'un autre projet. Au départ, j'avais tout compilé en x86, mes dll était également compilé dans cette version (sous Eclipse). Pour ce qui est des propriétés du projet, dans Répertoires VC++, j'avais rajouté les bons chemins d'accès au dossier contenant les .h dans les répertoires d'include, de même pour le dossier contenant les fichiers .lib et .dll dans les répertoires de bibliothèques. Et dans Editeurs de liens > entrée > Dépendances supplémentaires, j'ai également rajouté le nom de mes fichiers .lib
J'ai donc compilé tout ça en mode Release x32, tout marche très bien !

A présent, j'ai besoin de recompiler en x64 (et je suis passée en mode Debug), et c'est là ou ça ne fonctionne plus...
J'ai recompilé mes projets sous Eclipse en changeant les variables d'environnement afin d'obtenir les dll en x64, pour ça c'est OK.
Mais en repassant sous Visual, et en changeant les chemins d'accès pour qu'ils pointent vers les dossiers contenant les bonnes versions des .lib et .dll, lorsque je recompile j'ai une erreur de linker... :

error LNK2001: symbole externe non résolu

Je n'arrive pas à résoudre mon problème, si quelqu'un aurait une idée, ça m'éviterait encore des heures de casse-tête à tout essayé sans succès....

Je vous remercie par avance

Anaïs

[bacelar]

Le problème est simple, mais la résolution peut être compliquée.
Le problème, c'est que l'éditeur de lien ne trouve pas le code d'une fonction ou la définition d'une variable globale dans l'ensemble des .obj générés par le compilateur et des .lib que vous avez donné.
Il faut donc savoir où devrait être défini le symbole (fonction ou variable globale) que l'éditeur de lien ne trouve pas.

[Anais.serguier]

Merci pour votre réponse !

Dois-je indiquer dans une des propriétés du projet où il doit aller chercher les .obj ?
Car je ne me rappelle pas avoir du l'indiquer pour la compilation précédente mais c'est effectivement pour des .obj qu'il y a ces erreurs.

[bacelar]

Dois-je indiquer dans une des propriétés du projet où il doit aller chercher les .obj ?

Si votre chaine de compilation n'est pas trop exotique, chaque .cpp que compile le compilateur donne naissance à un .obj et la chaine le donne directement à manger à l'éditeur de lien.

mais c'est effectivement pour des .obj qu'il y a ces erreurs.

C'est normal, l’éditeur de lien n'a que des .obj et des .lib en entré.
Donc, quand il voit une connerie, c'est forcement dans un de ces types de fichier.
Mais, bon, faut pas voir fait X pour deviner à quel .cpp correspond quel obj.
Mais plus que l’endroit où l'éditeur de lien à vue une connerie, c'est ce que cherche l'éditeur de lien comme symbole ( la connerie qu'il à vue, c'est qu'on utilise un symbole et qu'il est pas foutu de le trouver, mais parce qu'on lui à pas donné les bonnes infos).
Mais après relecture de mon message, je comprends que mon message n'était pas clair.
Quand j'ai écrit "Où", ce n'était pas dans le sens de quelle ligne du code utilise le symbole manquant mais dans quel module (.obj ou .lib) est-il sensé être défini ?
Le plus simple, c'est de nous donner un message d'erreur complet.

[ternel]

Au passage, qu'est-ce qui te fait dire que la compilation de la bibliothèque en x64 a bien fonctionné?

[Bousk]

Utiliser une lib et dll compilée sous Eclispe avec Visual Studio ?
Pourquoi ne pas tout compiler sous VS ? Au moins tout devrait être compatible.

[Anais.serguier]

Quand j'ai écrit "Où", ce n'était pas dans le sens de quelle ligne du code utilise le symbole manquant mais dans quel module (.obj ou .lib) est-il sensé être défini ?
Le plus simple, c'est de nous donner un message d'erreur complet.

Et moi quand je disais où, c'était indiqué dans quel dossier se trouve ces fichiers .obj. Mais oui effectivement, ce n'est peut être pas nécessaire, ni même les .obj générés par mes bibliothèque sous Eclipse ?

Voici le message d'erreur :
1>LINK : warning LNK4075: ' /INCREMENTAL' ignoré à cause de la spécification '/LTCG'
1> Création de la bibliothèque ..\OpcUaWrapper\x64\Debug\OpcUaWrapper.lib et de l'objet ..\OpcUaWrapper\x64\Debug\OpcUaWrapper.exp
1>OpcUaClient.obj : error LNK2001: symbole externe non résolu "private: static class opcua::Mutex * opcua::RefCount::mutex" (?mutex@RefCount@opcua@@0PEAVMutex@2@EA)

Au passage, qu'est-ce qui te fait dire que la compilation de la bibliothèque en x64 a bien fonctionné?

J'ai réussi à récupérer .dll et .lib générés, et que j'ai une application test sous Eclipse me permettant de vérifier le bon fonctionnement de mes librairies.

Utiliser une lib et dll compilée sous Eclispe avec Visual Studio ?
Pourquoi ne pas tout compiler sous VS ? Au moins tout devrait être compatible.

Car les bibliothèques que j'ai compilée sous Eclipse ont été développé par une tiers personne sous Linux, c'est la procédure qu'elle m'a fournit afin de pouvoir le compiler sous Windows

[Anais.serguier]

J'ai trouvé... J'avais oublié de rajouter "USE_DLL" dans la définition du préprocess !

Merci à tous

[bacelar]

Cool, mais juste une remarque à 2 balles : si tu peux rapidement et facilement changer le nom de la constante de compilation pour un truc plus parlant que "USE_DLL", ça serait bien sympathique pour les mainteneurs du projet.