none
Débugguer DLL en C dans un projet C++, novice complet RRS feed

  • Question

  • Bonjour,

    j'ai développé un code qui utilise zlib et fonctionne très bien sous UNIX et Mac OS X.
    Sous windows, ce code ne fonctionne pas.
    Il se trouve que sous windows, un appel à une fonction de zlib retourne une erreur ce qui ne se produit pas sous les autres plate formes.

    Je me suis donc mis à visual c++, mais c'est la catastrophe.
    Après quelques heures, voilà ou j'en suis:
    mes points de départ sont
    - les sources C de zlib
    - les sources C++ de Sumatra-pdf
    Comme sumatra-pdf utilise zlib pour deux tâches bien différentes, je crée une deuxième version de zlib avec des noms différents, et seule la tâche qui me pose problème utilise cette deuxième version.

    Comment faire pour intégrer cette nouvelle zlib personnelle au projet sumatra-pdf, afin de pouvoir debugger pas à pas?

    J'ai essayé d'inclure directement le code source de my_zlib, cela n'est pas immédiat et j'ai réussi à corriger toutes les erreurs et les avertissement. Tous sauf un car je bute sur une incompatibilité:
    soit 'printf' et 'stderr' ne sont pas reconnus, soit j'inclus stdio.h dans le source et alors j'obtiens une erreur sur _vnsprintf dans stdio.h lui-même.
    C'est rageant.

    Pourriez-vous me donner des indications, sans oublier que je suis nouveau dans visual c++.

    vendredi 31 octobre 2008 10:59

Toutes les réponses

  • Pas de panique et un peu de méthode.

     

    Contrairement à d'autres compilateurs, par défaut, Visual C++ utilise un fichier séparé pour contenir les symboles générés lors de la compilation et de l'édition de lien. Ce fichier est un pdb (pour programm database). Si ce fichier a été généré (voir les options de compilations idoines) et est à coté de la dll lors de son chargement, le débugger de Visual C++ sera à même de continuer le debugging pas à pas même dans la dll.

    Je vous conseil donc de compilé votre dll zlib avec les options adéquates pour l'utilisation des fichiers pdb.

     

    Pour le problème lié à "stdio.h", c'est "vsnprintf" ou "vnsprintf"?

    Si c'est "vsnprintf", cette fonction a été signalé comme dangereuse d'un point de vue de la sécurité des programmes.

    C'est le sens de la macro _CRT_INSECURE_DEPRECATE positionné devant la déclaration de "vsnprintf" dans le fichier "stdio.h",

    Vous pouvez toujours définir la constante de compilation "_CRT_SECURE_NO_DEPRECATE" pour passer outre, et continuer à utiliser ces fonctions non sûres.

    lundi 3 novembre 2008 01:14
    Modérateur