Discussion :

[babar63]

Bonjour a tous,
Je suis actuellement en train de develloper une dll pour la premiere fois. Enfin fini et apres avoir corriger quelques erreurs j'obtiens bien ma dll et ma librairie statique. Le probleme c'est qu'en la testant, la dll fonctionne seulement lorsque je suis en mode release (pour la dll crée en release) et en mode debug (pour la dll crée en mode debug). Il semblerait que dans les deux cas le probleme viennent de la perte de l'adresse des paramètres envoyés dans une fonction membre . La dll a été créée a l'aide de Visual 2005 (projet Win32 dll). J'ai cherché dans la faq ainsi que deux autres articles appartenant a developpez mais je ne crois pas avoir trouvé de reponse!
Si cela peut vous aider voila comment j'ai defini ma configuration dans le projet :

Code :

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

1
2
3
4
5
6
7
//config.h
...
#ifdef _WINDLL
#define IMPORT_EXPORT __declspec(dllexport)
#else
#define IMPORT_EXPORT __declspec(dllimport)
#endif

Et dans la declaration de mes classes :

Code :

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

1
2
3
4
5
6
//class.h
#include <config.h>
...
class IMPORT_EXPORT MaClass{
...
};

J'avoue que j'ai un peu survolé l'étape de l'apprentissage pour créer une dll pour mieux me concentré sur le code ! Auriez-vous une idée d'ou se situe le probleme?
Merci d'avance, bonne journée

[koala01]

Salut,

J'aurais presque envie de dire que c'est normal.

En effet, il y a souvent une option de compilation (-DDEBUG, par exemple) rajoutee pour indiquer que la dll est compilee en mode debug, ce qui a pour effet d'y inclure une serie de choses, allant des assertions jusqu'a certains symboles, necessaires... au debuggage.

Tu devrais donc pouvoir utiliser la dll "debug" pour une application en mode release, mais, par contre, il est peu vraissemblable que l'utilisation de la dll release fonctionne avec une application en mode debug.

L'idéal est donc, sans doute, de fournir un nom legerement different pour la dll en mode debug, de manière à pouvoir faire le distingo, et permettre à l'utilisateur de choisir celle qu'il veut utiliser

Une convention que l'on rencontre souvent est, tout simplement, de rajouter la lettre d en fin de nom (madll.dll d'un cote, madlld.dll de l'autre),

[Jean-Marc.Bourguet]

Je ne connais pas Windows et ne peux donc pas commenter sur la nature et les causes du probleme. J'ai par contre beaucoup de mal a considerer comme normal de ne pas pouvoir utiliser une bibliotheque "release", qu'elle soit dynamique ou non, dans un build debug. (L'inverse, ne pas pouvoir utiliser la bibliotheque debug dans le build release, me semble plus comprehensible mais neanmoins pas particulierement acceptable et encore moins desirable).

[Médinoc]

Note: au passage sur la façon dont est faite ta DLL: À moins que ta DLL s'appelle "IMPORT.DLL", je te déconseille d'appeler ton define "IMPORT_EXPORT". Tu devrais lui donner un nom unique, typiquement NOMDELADLL_API.

[babar63]

Merci pour vos reponse, si je n'ai pas le choix alors je vais faire comme ca, c'est en effet la méthode que j'employait pour créer des librairies statiques. Mais quelques choses me chagrine quand meme. Pourquoi certaines dll (et meme lib) fonctionnent très bien dans les deux cas de figures, il doit bien exister une solution non? par exemple la librairie glut32.dll ou SDL.dll peuvent etre utilisées en mode debug et release...

[Médinoc]

Je dirais que ça doit surtout dépendre de la façon dont la DLL en question utilise la C Run-Time Library (CRT). Car si tu mélanges Debug et Release, tu auras deux versions de la CRT chargées dans le même processus...

[koala01]

C'est vrai que le terme "normal" est particulièrement inadapté...

j'aurais du utiliser le terme "compréhensible" (et encore )

Toujours est-il que cela peut, entre autre, venir de la manière dont ta bibliothèque est liée avec celle dont elle dépend en mode release et en mode debug...

S'il se fait, d'une manière ou d'une autre, qu'une distinction est effectuée dans le choix des bibliothèques dépendantes selon le mode de compilation choisi, tu te trouvera vraisemblablement confronté à cette nécessité de devoir créer une dll "release" et une "debug" (l'inverse étant tout aussi envisageable, bien sur )