dll : connaitre la version de mingw utilisée.

Bonjour,

Je suis actuellement en train de porter un exécutable sous Windows et après avoir, tant bien que mal, compilé toutes les bibliothèques nécessaires, je me retrouve avec un petit problème de dll.

En effet, lorsque je lance l'exécutable, j'ai une petite erreur :

Citation:

---

Le point d'entrée de procédure __gxx_personality_v0 est introuvable dans la bibliothèque de liens dynamiques libstdc++-6.dll

---

Que j'avais réussi à résoudre en changeant le fichier libstdc++-6.dll utilisé par un autre mais un peu plus tard j'ai eu une erreur (de tête ) :

Citation:

---

Le point d'entrée de procédure __gxx_personalitysj_v0 est introuvable dans la bibliothèque de liens dynamiques libstdc++-6.dll

---

Ces erreurs viendraient du fait que les dll utilisées n'auraient pas été compilée avec la même version de mingw.

J'aimerais donc savoir si vous connaissiez une méthode pour savoir quelles dll ont été compilées avec quelle version de mingw afin de savoir lesquelles remplacer/recompiler.

Bonjour,

Citation:

---

Envoyé par Neckara

...
J'aimerais donc savoir si vous connaissiez une méthode pour savoir quelles dll ont été compilées avec quelle version de mingw afin de savoir lesquelles remplacer/recompiler.

---

Sous Linux, les programmes sont compilés au format ELF. Ce format possède plusieurs sections d'entête (section header) dont la section .comment contient le nom et la version du compilateur.
Si le programme n'est pas "striper", on peut accéder à cette entête à l'aide de plusieurs méthode (readelf, objdump ou strings). Exemple avec strings :

Code:

---

strings -a libtest.so | grep -i gcc

---

ou avec objdump :

Code:

---

objdump -s --section .comment libtest.so

---

Vu que mingw contient les commandes readelf, objdump et strings, je pense (par pur spéculation) qu'elles ont été adapté au format des binaires Windows.
Cela ne coute rien d'essayer :ccool:

Merci pour votre réponse.

Kwariz m'avait donné une solution temporaire consistant à rechercher dans la dll grâce à (de tête) grep __gxx_personality_sj.

J'essayerais votre méthode dès que possible ;)

D'après objdump, il semblerait que les .dll soient au format

Citation:

---

file format pei-i386

---

strings quant à lui permet d'avoir une réponse de grep beaucoup plus lisible qu'en utilisant cat.

Citation:

---

Envoyé par Neckara

D'après objdump, il semblerait que les .dll soient au format ...

---

Il ne t'affiche pas le contenu de la section .comment parce qu’il ne trouve justement pas de section nommée .comment .
Ne connaissant pas l'entête du fichier, pas la peine de la spécifié. Essaie avec ça :

Code:

---

objdump -s libtest.so | grep -i gcc

---

Citation:

---

Envoyé par Neckara

strings quant à lui permet d'avoir une réponse de grep beaucoup plus lisible qu'en utilisant cat.

---

C'est le but, strings est spécialisés dans les fichiers non-textuels. Mais du coup tu as pu avoir la version de GCC ?

Avec objdump -s libtest.so | grep -i gcc ou objdump -s libtest.so | grep -i g++, je peux en effet trouver des numéro de version de gcc/g++ par contre, je ne sais pas si cela correspond à la version sj de mingw ou à l'autre version.

La version qui est mentionnée dans l'entête de l’exécutable est la version du compilateur (GCC), non pas celle de mingw.
A toi de voir qu'elles sont les versions de mingw qui sont installées sur ta machine, et qu'elle est celle qui possède la version de GCC indiquée.

Le problème c'est que mingw peut avoir la même version de gcc mais être ou non en sj.

Je pense que tu cours après le mauvais problème.
Tu cherches à savoir pourquoi le linker te lie ton executable avec une fonction se terminant par sj ou non :aie:
Ce que je t'ai montré plus haut c'est comment lire la version du compilateur (GCC en l’occurrence) qui a servit à compiler ton programme.
Mais l'erreur en elle-même que tu as donné semble plus être lié à l’utilisation d’exception, qui se règle en compilant avec g++ au lieu de gcc.

Je n'ai pas d'erreurs à la compilation mais à l'exécution :

J'ai deux dll stdc++-6.dll

Pour l'une j'ai une erreur du type :
entrée __gxx_personality_v0 introuvable dans le fichier stdc++-6.dll
Et quand je la remplace par la seconde je n'ai pas cette erreur mais j'ai un peu plus tard :
entrée __gxx_personalitysj_v0 introuvable dans le fichier stdc++-6.dll

Ces erreurs semblent provenir des dll que j'ai compilé avec code::block que je soupçonne de ne pas avoir pris le bon mingw.

As-tu essayé de recompiler tout ton projet, après l'avoir nettoyé?
puis de tester avec les deux libs.

Puisque le problème vient du besoin de linker un certain symbole, ne pourrais-tu pas rechercher le symbole personality dans tes DLL plutôt que la version?
Il me semble qu'un symbole non défini à linker avec une DLL figure aussi dans le binaire dépendant. De cette façon tu pourrais identifier les binaires qui dépendent de la "mauvaise" version de libstdc++, non?

Citation:

---

Envoyé par therwald

Puisque le problème vient du besoin de linker un certain symbole, ne pourrais-tu pas rechercher le symbole personality dans tes DLL plutôt que la version?
Il me semble qu'un symbole non défini à linker avec une DLL figure aussi dans le binaire dépendant. De cette façon tu pourrais identifier les binaires qui dépendent de la "mauvaise" version de libstdc++, non?

---

Oui, c'est ce que kwariz m'avait proposé de faire. Mais je me demandais s'il n'y avait pas une manière "générique"

Citation:

---

Envoyé par Neckara

J'ai deux dll stdc++-6.dll

---

Justement, pourquoi en a tu deux?
Mets le bin de mingw en tête de ton PATH, recompile toutes tes bibliothèques après un clean.
Ensuite copie LA version de stdc++-6.dll utilisée lors du build dans le dossier de compilation, pour être sûre d'utiliser la bonne dll (de peur que d'autres dll se balade dans ton PATH venant d'une ancienne installation de mingw).

C'est quand même l'enfer les histoires de dll sous Windows :aie:

Dès que j'aurais le temps j'essayerais de recompiler CEGUI et je verrais si les dll fonctionnent mieux ;)

Un conseil pour les dll de mingw (valable pour toutes les autres dll d'ailleurs) : toujours les mettre dans le répertoire d'exécution du projet. Ainsi même si tu changes de compilateur tu gardes la version compatible à ta dernière compilation.
Aller modifier le path est une mauvaise idée en général puisqu'on se retrouve avec un dll hell.

Bon, mingw, c'est un vrai enfer sous Windows, entre sa version SJLJ et sa version DW :aie:

Est-ce qu'il n'existe pas un moyen de savoir si une dll est compatible avec un compilateur donné ?

J'ai malheureusement peur que non. Et oui c'est un véritable enfer.

Je n'avais pas fait la remarque sur l'autre sujet, mais elle s'y prêtait aussi. L'absence d'ABI en C++ rend l'utilisation de bibliothèque liés dynamiquement plus galère qu'en C (par exemple), à moins d'avoir une API flat C. Ou d'utiliser un environnement compilé entièrement avec le même compilateur et les mêmes options (*).

Tu veux pas avoir de problèmes, alors compiles et lies tout statiquement avec le même compilateur. Ça marche très bien et c'est robuste. Tu veux faire un système de plugin ? Mets le à plat et encapsule à travers du C. C'est encore le meilleur moyen d'utiliser des bibliothèques dynamiques en C++ sans avoir de problèmes.

Sinon, tu prends ton courage à deux main, le man de gcc/mingw, l'ABI Itanium. Et tu t'assures de n'assembler que des éléments qui peuvent l'être.

Pour la question : "savoir si une DLL est compatible avec un compilateur donné ?" Dans le cas de la bibliothèque standard, c'est quand même trivial : la dll fournit avec ton compilateur. Après si tu utilises des DLL venant d'un peu n'importe où, faut pas trop t'étonner d'avoir des problèmes.

(*) Ça implique de recompiler toutes les dépendances si tu changes de compilateur.

Merci pour ta réponse.

Qu'entends-tu par "mettre à plat" ?

Sinon, j'ai enfin réussi à tout compiler \o/, j'ai réussi à lancer mon programme pour qu'il plante en me disant qu'un module manque. Résultat j'ai une dernière bibliothèque à compiler... *va se chercher un câble wifi pour se pendre*

Lorsque j'essaye de compiler cette bibliothèque ( une sous-bibliothèque de CEGUI ), j'ai, lors de l'édition des liens une référence non-trouvée : __gxx_personality_v0.

Ce problème semble venir de la libexpat qui est pourtant écrite en C, j'ai rajouté un -lstdc++ mais sans résultats :aie:

Donc il y a aussi des problèmes avec les .a C.

Je pense que je vais créer un sujet dans quelques temps à ce propos.

Sinon, sur la base de choses comme ça:
http://chadaustin.me/cppinterface.html
il me semble possible d'avoir des lib c++ qui exposent des objets avec une facade. Dans ce cas, la fonction libre en extern "C" sert de factory, il y a quelques complications mais après l'avoir déjà essayé entre gcc/mingw et MSVC, ça semble marcher.
Il n'en reste pas moins qu'il y a des restrictions (pas de propagation d'exception à travers la DLL boundary, par d'instances de types de la STL transmis à travers la boundary...ça peut compliquer les choses et probablement que ça coûte en perf...

Si tu as réussi, je me permets de poser une question: SJ, DW... Ça veut dire quoi tous ces sigles?

En fait apparemment je n'ai pas tout à fait réussi, irrlicht semble être incompatible avec le sjlj :aie:

Heureusement Irrlicht 1.8 est déjà compilée et semble marcher, il faut donc que je recompile tout en dw2 :aie:

Si j'ai bien compris, le sjlj va gérer les exceptions avec des setjump/longjump et dw2 va les gérer autrement.

dw2 est apparemment le mingw "officel", et serait plus rapide au niveau des exception par contre il me semble qu'il a des problèmes avec pthread (?).

Merci.
Je suis tombé sur un site qui dit le contraire sur le choix entre sjlj et dw2, mais j'ignore quel âge il a.

Citation:

---

GCC currently supports two methods of stack frame unwinding: Dwarf-2 (DW2) or
SJLJ (setjmp/longjmp). Until recently, only SJLJ has been available for the
Windows platform. This affects you, the end user, primarily in programs that
throw and catch exceptions. Programs which utilize the DW2 unwind method
generally execute more quickly than programs which utilize the SJLJ method,
because the DW2 method incurs no runtime overhead until an exception is thrown.
However, the DW2 method does incur a size penalty on code that must handle
exceptions, and more importantly the DW2 method cannot yet unwind (pass
exceptions) through "foreign" stack frames: stack frames compiled by another
non-DW2-enabled compiler, such as OS DLLs in a Windows callback.

This means that you should in general choose the SJLJ version of the TDM-GCC
builds unless you know you need faster exception-aware programs and can be
certain you will never throw an exception through a foreign stack area.

---

J'ai dû le lire trop vite :aie:

J'ai surtout retenu :
- DW2 : mingw officiel à utiliser de préférence
- SJLJ : non-supporté par Irrlicht.

ll faut aussi savoir que les dll DW2 sont incompatibles avec les dll SJLJ.

Neckara,

Juste pour info, J'ai commencé à coder sous Linux, puis est basculé sous Windows. J'ai installé la version qt avec Mingw. Alors pourquoi recompiler les Dlls ? tu as peut être tes raisons.

qmake pour générer mon Makefile et puis voila conversion terminée. ce fut génial.

Tout simplement parce que certaines dll ne sont pas compatibles avec le compilateur ou qu'on ne trouve pas certaines dll.

Citation:

---

Envoyé par chrtophe

Alors pourquoi recompiler les Dlls ? tu as peut être tes raisons.

---

Peut-être pour éviter les soucis/acrobaties que nous venons d'évoquer au long de ce thread? ;)