Discussion :

[Neckara]

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 :

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

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.

[saad.hessane]

Bonjour,

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

Sélectionner tout - Visualiser dans une fenêtre à part

strings -a libtest.so | grep -i gcc

ou avec objdump :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Neckara]

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

[Neckara]

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

file format pei-i386

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

[saad.hessane]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

objdump -s libtest.so | grep -i gcc

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 ?

[Neckara]

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.

[saad.hessane]

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.

[Neckara]

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

[saad.hessane]

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

[Neckara]

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.

[ternel]

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

[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?

[Neckara]

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"

[saad.hessane]

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

[Neckara]

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

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

[germinolegrand]

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.

[Neckara]

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

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

[germinolegrand]

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

[Flob90]

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.

[Neckara]

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

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.