Version imprimable
Bonjour, j'ai un problème de lien.
J'ai créé une lib statique sous MSVC 2008 express.
Si je lie cette lib à un un exe créé avec le même compilateur, tout se passe bien.
Par contre j'ai undefined reference si je lie cette même lib statique à un bin compilé avec Mingw (gcc 4.4.0)
(sous win7/x64)
J'ai cru lire qqpart qu'une lib statique MS est incompatible avec un compilateur MinGw.
Est ce que quelqu'un a déjà réalisé ça?
Salut,C'est normal, les bibliothèques statiques ne sont compatible qu'avec la version du compilateur avec lequel elles ont été compiléeCitation:
Envoyé par winzzz
Effectivement.Citation:
J'ai cru lire qqpart qu'une lib statique MS est incompatible avec un compilateur MinGw.
Contrairement à C, il n'y a pas d'ABI standard en C++, ce qui fait que tous les compilateurs en font plus ou moins "à leur tête" en ce qui concerne les bibliothèques statiques. (note d'ailleurs qu'une dll exclusivement C++ ne pourra, elle aussi, être utilisée qu'avec le compilateur avec lequel elle a été compilée ;))
Le gros responsable de cet état de fait est le système de "mangling" des fonctions C++:
En C, tu les fonctions ne sont pas surchargeables et ne peuvent pas se trouver dans une structure. Tu ne peux jamais avoir qu'une et une seule implémentation d'une fonction portant un nom donné, et, par voie de conséquence, tu il n'est pas possible d'avoir de conflit entre les noms des différentes fonctions au moment de l'édition des liens.
Par contre, en C++, tu peux surcharger une fonction (avoir deux fonctions portant le même nom, mais présentant une signature différente), tu peux décider de placer cette fonction dans la structure sur laquelle elle agit (c'est la base de la programmation OO ;)) et tu peux même décider de l'accessibilité que tu veux permettre, voire, décider de la redéfinir dans les classes dérivées.
Tout cela fait que tu perd l'unicité de la relation qu'il peut y avoir entre une fonction et son nom, comme on le remarque en C.
Or, après la compilation, il y a un outil que l'on appelle "l'éditeur de liens", qui vient faire correspondre les appels aux différentes fonctions avec l'adresse à laquelle elles commencent.
Pour que chaque implémentation binaire de fonction soit identifiable par un symbole unique en C++, il faut donc "décorer" le nom de la fonction avec différents symboles susceptibles de représenter les différents cas de figures.
Cette décoration des symboles s'appelle le "mangling".
Malheureusement, les règles de mangling ne sont pas standardisées, ce qui fait qu'un nom décoré "à la mode Visual C++" ne correspondra pas, pour la même fonction, au nom décoré "à la mode Gcc", ou avec n'importe quel autre compilateur (seul ambarcadero respecte plus ou moins la forme de Visual C++, à ma connaissance (et je peux encore me tromper sur ce coup :P) )
C'est pour cela que alors que le code binaire des fonctions sera sans doute identiques (ou en tout cas fortement compatible), on ne peut pas effectuer l'édition de liens avec une bibliothèque statique compilée avec un autre compilateur que celui que l'on utilise :P
C'est impossible, sans recompiler la bibliothèque avec le compilateur que tu veux utiliser.Citation:
Est ce que quelqu'un a déjà réalisé ça?
Il est éventuellement possible de créer une "bibliothèque d'importation" pour les dll, mais c'est un autre débat ;)
Merci beaucoup pour cette réponse détaillée!! :ccool:
J'ai lu des paquets de howto sur les dlls mais grâce à ton explication je comprends mieux le pourquoi de la chose.
Effectivement, je peux utiliser des dll de MS vers GCC et inversement si je précise que mes fonctions exportées sont "extern C"
ce n'est pas possible de faire la même chose avec des lib statiques? et si je compile avec un compilateur C ma lib statique (sous MS) , je devrais pouvoir la liée à mon bin (gcc-c++), non?
En fait, je parlais des fonctions non déclarées extern "C"...
Toutes ne peuvent en effet pas l'être parce qu'elles se doivent, au minimum, de respecter les règles de C en terme de signature.
Non, la solution à laquelle je pensais pour "adapter" ue dll C++ compilée sous VC++ à Gcc passe plutôt par quelques outils sympa comme dlltools et autres joyeusetés permettant d'obtenir un libMadll.a qui pourra être utilisé par ld lors de l'édition de liens, et qui sera mis en rapport avec la dll :P:aie:
De plus, si tu pars de l'idée de:
Autant, directement, compiler ta bibliothèque avec Gcc, sans commencer à modifier le projet ;)
- déclarer l'ensemble de tes fonctions extern "C"
- compiler (avec VC++) ta bibliothèque
Il faut bien te dire que, contrairement à une dll, les bibliothèques statiques ne seront jamais founries "telles quelles" avec l'application: seule les parties utilisées du code binaire qu'elle contiennent sera directement inséré dans ton exécutable.
Dés lors, pourquoi se fatiguer à essayer de contourner un problème qui n'en est en réalité pas un :question:
Cela aura, en outre, peut être l'intérêt de mettre le doigt sur certains problèmes qui auraient pu "passer au bleu" avec le compilateur d'origine, sans *forcément* aller jusqu'à chercher la portabilité complète ;)
Je suis parti depuis des lustres sur un gros projet Qt/mingw et j'ai besoin d'accéder à des infos matériels via la lib WMI de msn.
Ca me paraissait plus simple de pondre une petite lib statique que je rajouterai à mon projet mingw
Je vais faire la même chose avec une dll
Merci pour ces explications.
Sauf erreur, WMI est une bibliothèque qui n'existe que pour les systèmes 64 bits.Citation:
Envoyé par winzzz
Enfin, je dis cela parce que c'est une des bibliothèques d'importations que l'on trouve dans le projet mingw-w64 (la version "64 bits" de MinGW ;)) et qui ne se trouve que dans le dossier propres aux bibliothèques 64 bits :P
Il serait donc doublement normal que ld ne trouve pas la bibliothèque si tu travailles avec la version 32 bits de MinGW, car, quoi que tu fasse, tu ne pourra pas aisément convertir cette bibliothèque pour qu'elle fonctionne en version 32 bits :P
Il y a donc une question à se poser: as tu réellement besoin de cette bibliothèque :question:
Si ce n'est pas le cas, essaye de supprimer cette dépendance.
Si tu en as réellement besoin tourne toi peut être vers la version 64 bits de mingw ;)
Edit : cela impliquera, malheureusement, que tu doive te procurer une version correspondante de Qt, et, comme je crains qu'il n'y ait pas encore de binaire disponible de cette dernière pour la version actuelle de mingw-w64, que tu risque de devoir la compiler "par toi même" :P
harrrg c'était pas du tout prévu ça!
Je développe sur win7/x64 pour des clients xp/x86
Je n'ai pas encore trouvé le temps pour compiler Qt en 64 bits (pour anticiper la migration) : je fais donc tout en 32 bits
J'ai compilé une dll MS x86 pour manipuler la lib WMI.
Ca marche lorsque je l'appelle depuis un bin compilé avec MSVC 2008 express (32 bits)
Mais la dll ne fonctionne plus lorsque je la charge depuis un bin compilé avec gcc 32 bits.
La dll se charge bien mais elle contient une fonction "CoInitializeEx" (pour l'init de la COM lib) qui ne parvient pas à s'initialiser.
Je ne connais pas grand chose en prg système windows.
Est ce que tu aurais une petite idée par hasard?
WMI n'est pas une lib.
C'est un composant logiciel COM, aussi bien 32 que 64 bits.
CoInitializeEx n'est pas une fonction de la dll, mais une fonction Win32 à appeler depuis chaque thread devant utiliser des composants COM.
Vous devez appeler cette fonction Win32(http://msdn.microsoft.com/en-us/libr...43(VS.85).aspx ou http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx) dans votre thread avant tout appel au composant WMI.
ça marche!
Si j'utilise CoInitialize à la place de CoInitializeEx (je crois que la différence tourne autour d'une gestion single ou multi-threading)
Merci beaucoup à vous deux qui m'avez sortie de ce marécage windozien