Discussion :

[darkman19320]

Bonjour tout le monde,

Je cherche depuis quelques temps une solution à mon problème: je dois distribuer notre bibliothèque statique compiler avec VS 2010 (ou VS2012) en mode "Release" mais les utilisateurs doivent quand même pouvoir debugué leur application.

Avec G++, aucun problème, mais avec VS 2010, j'ai toujours un problème au niveau de l'édition de liens:

Code :

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

error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2'

Avez-vous déjà été dans cette situation? Comment l'avez-vous résolu?

Merci pour tout!

[darkman19320]

Bonjour,

Je reviens vers vous pour les différentes avancées que j'ai effectué: il est apparemment impossible de lier un bibliothèque en mode Release (compilée avec l'option /MD) avec une application en mode Debug.

Ceci viendrait du fait que Visual Studio cherche à détecter par défaut si les itérateurs de la bibliothèque standard sont utilisés correctement lors de la compilation et retourne une erreur dans le cas contraire.

Je comprends l'idée, mais de là à empêcher l'édition de liens simplement pour ça est à mon sens complètement tordu.
J'ai essayé de compiler avec différentes options mais rien y fait... J'ai même essayé de fixer la valeur de _ITERATOR_DEBUG_LEVEL mais même résultat d'échec.

Je suis en train de me demander si je ne vais pas utiliser g++ (distribué avec mingw32) et essayé de créer une bibliothèque statique "linkable" avec une application Visual Studio. (Est-ce faisable? C'est une autre question ^^)

[moldavi]

Bonjour.

Il y a une discussion ici :

http://www.developpez.net/forums/d11..._level-resolu/

Bonjour,

Je comprends l'idée, mais de là à empêcher l'édition de liens simplement pour ça est à mon sens complètement tordu.

Ce n'est pas tordu, c'est tout simplement pour éviter le crash de l'application.

Les composants de la stl compilés en mode debug, ne sont pas les mêmes que ceux compilés en mode release. Ils ne font pas la même taille mémoire. Donc un objet debug de la stl, passé à un objet release de la stl, ça ne marche pas. Ca plante grave même... Ce serait un peu comme passer une classe string à une classe vector (je schématise).

Les objets de la stl en mode debug contienne des informations supplémentaires pour le debugage. C'est pratique et c'est sympa pour trouver rapidement ses erreurs, peut-être aussi pour le profiling et les tests (à confirmer). Les objets de la stl en mode release ne contiennent que le nécessaire, pour un gain de taille mémoire minimum, plus des optimisations (des pointeurs de partout) pour une efficacité maximum. Voilà, c'est le fonctionnement de la stl sous Windows. Y a des avantages et des inconvénients.

J'ai eu ce cas similaire mais entre un exécutable et une dll COM. Comme la liaison se fait à l'exécution et non à la compilation, pas de problème de compilation. Mais à l'exécution, gros plantage. Je crois que je me suis arraché les cheveux plusieurs heures avant de comprendre.

[darkman19320]

Merci pour ta réponse!

Je comprends mieux pourquoi VS interdit la compilation entre Release et Debug.

J'ai pourtant une question qui me trotte toujours entre mes deux oreilles: comment certaines bibliothèques peuvent être utilisé en Debug ou Release avec différentes versions de VS (je pense en particulier à Cplex)?

Encore merci!

[white_tentacle]

Si elles n’utilisent pas la stl dans leur interface.

Théoriquement, compiler en debug/release ne change pas la taille des objets, l’adresse des fonctions exportées, etc. La STL microsoft est un cas particulier (celle de gnu n’a d’ailleurs pas le problème). De manière générale, d’ailleurs, je trouve le compilo MS chiant parce qu’il fait trop de différences de comportement entre les profils par défaut de debug et de release.

Pour tes clients, je pense qu’il est possible de compiler en mode debug (donc, sans les optims, avec tous les symboles), tout en utilisant la STL release (celle qu’utilise ta bibliothèque). Par contre, je n’ai pas de visual sous la main pour retrouver comment on fait ça.

[darkman19320]

Merci pour la réponse.

Je vais creuser cette idée sur l'utilisation de la stl en Release par défaut en Debug.

[Médinoc]

J'ai eu ce cas similaire mais entre un exécutable et une dll COM. Comme la liaison se fait à l'exécution et non à la compilation, pas de problème de compilation. Mais à l'exécution, gros plantage. Je crois que je me suis arraché les cheveux plusieurs heures avant de comprendre.

J'ai du mal à voir comment ça peut arriver pour une DLL COM, qui est censée répondre à un standard binaire fixé...

[moldavi]

Bonjour Médinoc.

J'ai du mal à voir comment ça peut arriver pour une DLL COM, qui est censée répondre à un standard binaire fixé...

La réponse est simple. Les string de la STL ne sont pas dans le standard binaire fixé. Par contre un void* est dans le standard.

Le void* est le seul moyen d'échanger des objets de la STL avec une dll COM. On passe donc un pointeur. Et c'est là que l'on se rend vite compte qu'une string de la STL compilée en mode debug, ce n'est pas la même string que la version release.

Ci-joint un code qui reproduit le problème (Visual Studio 2010/Windows SDK 7.1).

Il faut d'abord compiler la dll et le programme en mode debug. Il faut enregistrer la dll en mode administrateur. Il y a un fichier REGISTER.bat dans le projet. Modifier le pour y ajouter le chemin d'accès complet à la dll (entre-guillemets s'il y a des espaces).

Exécuter le programme, normalement tout va bien (il y a deux MessageBox).

Ensuite compiler seuleument la dll en mode release. L'enregistrer avec les droits administrateurs. Exécuter le programme en mode debug, enjoy...

[Médinoc]

En gros, tu as triché avec les pointeurs void* pour passer une string STL à travers la frontière d'un appel COM, au lieu de, disons, un pointeur vers son premier caractère (et je ne parle pas des BSTR, je suppose que tu avais une raison de ne pas les employer, comme "tout le restant du programme utilise des char").