Distribution bibliothèque statique en mode Release

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:

---

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!

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 ^^)

Bonjour.

Il y a une discussion ici :

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

Citation:

---

Envoyé par darkman19320

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.

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!

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.

Merci pour la réponse.

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

Citation:

---

Envoyé par moldavi

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é...

Bonjour Médinoc.

Citation:

---

Envoyé par 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...

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").

Re.

C'est un bout de code qui a 8 ans d'âge. C'était pendant ma transition du C au C++, et la découverte de COM. J'en avais un peu ras le bol de la gestion des char et les string/vector étaient mes sauveurs. Et un peu naïvement, j'ai réussi à utiliser ces conteneurs avec COM.

Mais c'est la seule fois, après j'ai arrêté.

Bonsoir tout le monde,

Je reviens vers vous car je n'ai pas réussi à configurer VS pour compiler ma bibliothèque en Debug avec la STL en Release.

De plus je viens de constater un problème beaucoup plus génant: quand je fourni ma bibliothèque compilée en mode debug (sans les source de celle-ci et simplement le .lib), que je debug une application et que je fais tu parcours pas-à-pas (Step into), je vois le code de ma bibliothèque!!

C'est un comportement normal sous VS? Est-ce qu'on peut l'empêcher?

Merci pour tout!

Citation:

---

Envoyé par darkman19320

Je reviens vers vous car je n'ai pas réussi à configurer VS pour compiler ma bibliothèque en Debug avec la STL en Release.

---

Il faut jeter un oeil sur les directives de compilation en relation avec la STL. Mais au vue des informations trouvées sur le net, ça va être compliqué. Le mieux pour avoir une réponse définitive, c'est de contacter le support Microsoft.

Citation:

---

Envoyé par darkman19320

De plus je viens de constater un problème beaucoup plus génant: quand je fourni ma bibliothèque compilée en mode debug (sans les source de celle-ci et simplement le .lib), que je debug une application et que je fais tu parcours pas-à-pas (Step into), je vois le code de ma bibliothèque!!

---

Je crois que ce sont les fichiers .pdb qui permettent cela. Par défaut, Visual compile en mode release avec les informations de débugage. Je le désactive toujours.

Le code n'est visible que si tu as les sources en plus du .pdb, et que ces sources n'ont pas bougé.

Les infos de débogage sont toujours utiles, même en Release. Surtout en Release en fait, car ça permet de trouver les Heisenbugs.