Bonjour,

Ayant eu un problème avec la SFML (problème de portabilité en quelque sorte), j'ai pensé que changer de compilateur pouvait être une solution, j'ai donc changer le MinGW de mon Code::block pour la version avec laquelle à été compilé la SFML (même si je ne comprend pas trop ce principe). Or, maintenant mes programmes qui utilisaient l'autre compilateur ne fonctionne plus et me dise qu'il y a une erreur de point d'entrée procédure dans mes dll, plus précisement le : __gxx_personality_v0 de chaque dll (window, system et graphics). Alors j'aimerais savoir en quoi mon compilateur change tout ça alors qu'il est censé être mieux adapté à la SFML et aussi des indications sur le fcontionnement des dll, merci!

Salut,

DeveCout a écrit:

Bonjour,

j'ai donc changer le MinGW de mon Code::block pour la version avec laquelle à été compilé la SFML (même si je ne comprend pas trop ce principe).

Commençons donc par là...

Code::Blocks est ce que l'on appelle un EDI (Environnement de Développement Intégré) ou un IDE (Integrated Development Environement) en anglais.

Pour faire simple, c'est un programme dont le but est de regrouper toute une série d'outils différents tels que:

• un éditeur de texte
• un outil qui permet de décrire ton projet et donc de transmettre les bonnes options à
• ce que l'on appelle la "chaine de compilation".

Le tout en veillant à ce que tous les outils puissent communiquer correctement les uns avec les autres (par exemple, pour te permettre de voir, au niveau de ton éditeur de texte les valeurs des données auxquelles le débogueur donne accès, même si c'est une manière de voir très simplifiée )

On parle de "chaine de compilation" parce que la transformation de ton code source en programme exécutable se fait en différentes étapes, et que chaque étape est prise en charge par un programme différent.  Pour faire simple, on pourrait dire que ton code source va passer "dans les pattes" de programmes comme

• le préprocesseur, qui va s'occuper de traiter les directives #include, #ifdef / #ifndef #if/else #endif et #define, ainsi que les symboles définis grâce à ces directive
• le compilateur en lui-même qui va générer le code binaire exécutable pour chacun des fichier .cpp de ton projet en créant ce que l'on appel des "fichiers objets"
• l'éditeur de liens qui va regrouper tous les fichiers objets générés par le compilateur pour créer l'exécutable, en y ajoutant au besoin les fonctionnalités issues de bibliothèque tièrces
• le développeur, qui aura la capacité d'interpréter correctement les données en mémoire et de les associer à ton code source
• un générateur d'archives pour la création de bibliothèques
• d'autres outils plus ou moins utiles selon les circonstances

A priori, la manière dont ces différents outils communiquent "avec l'extérieur" (entre autres, avec l'EDI) est suffisamment bien définie et stable pour permettre aux différents EDI d'être complètement indépendant de la chaine de compilation qu'ils utilisent.

C'est, du moins, le cas pour des EDI comme Code::Blocks, QtCreator ou Eclipse avec le module CDT.

Si bien que, quand tu décide de changer la chaine de compilation, c'est un peu comme si tu changeais la roue à ta voiture pour ton EDI: Tant qu'il s'agit d'un remplacement, ton EDI sera content.  Il n'y a vraiment que si tu retires la chaine de compilation sans en mettre une autre à la place qu'il ne saura plus quoi faire

DeveCout a écrit:

Or, maintenant mes programmes qui utilisaient l'autre compilateur ne fonctionne plus et me dise qu'il y a une erreur de point d'entrée procédure dans mes dll

Ca, c'est l'un des plus gros problèmes du C++: à l'heure actuelle l'ABI (Application Binary Interface, ou, si tu préfères en français l'interface binaire applicative) n'est pas encore "stabilisée".

Pour faire simple, l'ABI détermine la manière dont un programme (un fichier *.exe, sous windows) va "discuter" avec avec les bibliothèques dynamiques (les *.dll sous windows) qui fournissent certaines fonctionnalités dont le programme a besoin pour fonctionner.

Comme cette ABI n'est pas stabilisée, elle est susceptible de changer pour un tas de raisons différentes, parmi lesquelles on peut citer:

• parce que le programme et la dll n'ont pas été générées avec le même compilateur
• parce que le programme et la dll ont été générées avec des versions différentes du même compilateur
• parce que le programme et la dll ont été générée avec la même version du même compilateur, mais avec des options de compilation différentes.

En remplaçant la version de Gcc fournie par Code::Blocks par la version fournie par SFML, tu as aussi remplacer la version d'origine de la dll nommé libstdc++ par celle fournie avec la version de Gcc fournie par la SFML.

Et, du coup, tu te trouves sans doute face à la deuxième situation avec tes anciens projets: la dll et le programme ont été compilés avec des versions différentes du compilateur.

Cela n'a rien de catastrophique, vu qu'il suffira le plus souvent de ... recompiler tes différents projets pour corriger le problème.  De cette manière, tes projets seront compilés avec la même version de Gcc et les mêmes options de compilation que le compilateur qui a servi à la création de la dll libstdc++, et tout rentrera dans l'ordre