Discussion :

[winzzz]

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?

[koala01]

Salut,

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)

C'est normal, les bibliothèques statiques ne sont compatible qu'avec la version du compilateur avec lequel elles ont été compilée

J'ai cru lire qqpart qu'une lib statique MS est incompatible avec un compilateur MinGw.

Effectivement.

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

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

Est ce que quelqu'un a déjà réalisé ça?

C'est impossible, sans recompiler la bibliothèque avec le compilateur que tu veux utiliser.

Il est éventuellement possible de créer une "bibliothèque d'importation" pour les dll, mais c'est un autre débat

[winzzz]

Merci beaucoup pour cette réponse détaillée!!

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?

[koala01]

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

De plus, si tu pars de l'idée de:

1. déclarer l'ensemble de tes fonctions extern "C"
2. compiler (avec VC++) ta bibliothèque

Autant, directement, compiler ta bibliothèque avec Gcc, sans commencer à modifier le projet

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

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

[winzzz]

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.

[koala01]

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.

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

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

Il y a donc une question à se poser: as tu réellement besoin de cette bibliothèque

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"