Discussion :

[42toto]

Bonjour,

Je suis actuellement sous Ubuntu 12.04 et je suis sur un projet de c++ incluant de la SFML. J'aimerais aujourd'hui passer ce projet sur Windows, et donc faire un executable .exe. J'utilise mingw, voila comment je compile:

i586-mingw32msvc-g++ *.cpp -o mon_executable.exe -lsfml-graphics -lsfml-window -lsfml-system -lsfml-audio -Wall -Wextra -Werror -O2

Il compile et me sort donc bien mon .exe.
Or quand je l'execute "wine ./mon_executable.exe"
J'ai cette erreur la,

err:module:import_dll Library sfml-graphics-2.dll (which is needed by L"Z:\\home\\toto\\totoprojet\\mon_executable.exe") not found
err:module:import_dll Library sfml-system-2.dll (which is needed by L"Z:\\home\\toto\\totoprojet\\mon_executable.exe") not found
err:module:import_dll Library sfml-window-2.dll (which is needed by L"Z:\\home\\toto\\totoprojet\\tmon_executable.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\toto\\totoprojet\\mon_executable.exe" failed, status c0000135

Quelqu'un peut-il m'aider s'il vous plait ?

[gnto]

Bonjour,

Le binaire ne trouve pas les DLL. Sous windows, le binaire va chercher les dll d'abord a la racine du binaire, s'il ne trouve pas dans il parcourt les repertoires systeme et s'il ne trouve toujours pas il parcourt les repertoires de la variable d'environnement PATH.

A toi de lui dire ou sont les dll.

[42toto]

Merci de ta réponse, sais tu comment puis-je lier mes dll à mon executable quand je compile ? (statiquement donc).

[gnto]

Les DLL sont des bibliothèques chargées dynamiquement. Elle ne sont pas lier statiquement au binaire.

Mais tu peux lier statiquement des bibliothèques .lib (sous windows) ou .a (sous unix) afin ne les inclure directement dans le binaire.

[42toto]

Ok, j'ai donc compilé comme ceci:

Code :

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

i586-mingw32msvc-g++ *.cpp -L /usr/i586-mingw32msvc/bin/sfml-audio-2.dll /usr/i586-mingw32msvc/bin/sfml-graphics-2.dll /usr/i586-mingw32msvc/bin/sfml-system-2.dll

J'ai lu sur certains sites qu'il fallait mettre tous les .dll dans le dossier ou se trouve l'executable, ce que j'ai fait, mais il avait l'air de merder encore plus. Donc tous mes .dll se trouve dans le repertoire à mettre: /usr/i586-mingw32mscv/bin.

Je compile, et voici ce qu'il me donne:

/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/libstdc++.a(stubs.o):(.text+0x160): multiple definition of `_powf'
/tmp/ccES6eRT.o:Brain.cpp:(.text$powf[_powf]+0x0): first defined here
/tmp/ccES6eRT.o:Brain.cpp:(.text+0x341): undefined reference to `__imp___ZN2sf5Mouse15isButtonPressedENS0_6ButtonE'
/tmp/ccES6eRT.o:Brain.cpp:(.text+0x356): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
/tmp/ccARR2FE.o:Game.cpp:(.text+0x7df): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
/tmp/ccARR2FE.o:Game.cpp:(.text+0x88f): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
/tmp/ccAZXOI2.o:main.cpp:(.text+0x29b): undefined reference to `__imp___ZN2sf9VideoModeC1Ejjj'
/tmp/ccAZXOI2.o:main.cpp:(.text+0x3e7): undefined reference to `__imp___ZN2sf6Window5closeEv'
/tmp/ccAZXOI2.o:main.cpp:(.text+0x572): undefined reference to `__imp___ZN2sf6Window9pollEventERNS_5EventE'
/tmp/ccAZXOI2.o:main.cpp:(.text+0x5d9): undefined reference to `__imp___ZN2sf6Window7displayEv'
/tmp/ccAZXOI2.o:main.cpp:(.text+0x5ed): undefined reference to `__imp___ZNK2sf6Window6isOpenEv'
/tmp/ccyjc1wh.o:Menu.cpp:(.text+0x42d): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
/tmp/ccqWi9LI.o:MenuModule.cpp:(.text+0x242): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
/tmp/cc8rEyMa.o:MenuOptions.cpp:(.text+0x3e0): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
/tmp/cckJ6zRB.o:MenuSuccess.cpp:(.text+0x3e0): undefined reference to `__imp___ZN2sf5Mouse11getPositionERKNS_6WindowE'
collect2: ld returned 1 exit status

C'est un peu indigeste comme erreur, une idée ?

[Kaamui]

Essaie avec i586-mingw32msvc-gcc.

Ensuite pour tes erreurs de link, tu ne peux pas utiliser des dll qui ont un format de fichier et un encodage propre aux OS Microsoft, donc tu ne peux pas les utiliser pour compiler ton projet alors que tu es sous un autre OS. Si tu veux utiliser Wine, il faut peut-être effectivement que tu place les dll dans le répertoire de ton projet .exe, et linker avec les lib dynamiques (.so ou .sh, etc selon ton OS) adaptées, mais j'ai un gros doute sur le résultat où la faisabilité. La meilleure solution reste comme déjà évoqué que tu link statiquement les libs de la SFML.

[gnto]

Essaie avec i586-mingw32msvc-gcc.

Pourquoi utiliser le compilateur C s'il fait du Cpp ?

Je pense que ton problème vient des conventions de nommage des methodes dans la DLL.

Il faut surement retravailler la Dll pour que les nom des fonctions soient dans la bonne convention.
=> http://www.mingw.org/wiki/CreateImportLibraries

Ensuite pour tes erreurs de link, tu ne peux pas utiliser des dll qui ont un format de fichier et un encodage propre aux OS Microsoft, donc tu ne peux pas les utiliser pour compiler ton projet alors que tu es sous un autre OS. Si tu veux utiliser Wine, il faut peut-être effectivement que tu place les dll dans le répertoire de ton projet .exe, et linker avec les lib dynamiques (.so ou .sh, etc selon ton OS) adaptées, mais j'ai un gros doute sur le résultat où la faisabilité. La meilleure solution reste comme déjà évoqué que tu link statiquement les libs de la SFML.

Y'a pas d'encodage propre Microsoft, mais des conventions de nommage différentes que l'on peut choisir sous windows.

[42toto]

Je vais me debrouiller, merci pour vos réponses !

[gnto]

Essaie ça :

Code :

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

i586-mingw32msvc-g++ *.cpp -L /usr/i586-mingw32msvc/bin/  -lsfml-graphics -lsfml-window -lsfml-system -lsfml-audio

[42toto]

J'avais déjà essayé et il m'avait mis cette erreur:

/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/libstdc++.a(stubs.o):(.text+0x160): multiple definition of `_powf'
/tmp/ccbLh5RD.o:Brain.cpp:(.text$powf[_powf]+0x0)first defined here
collect2: ld returned 1 exit status

Et cela ne vient pas du fichier brain.cpp car j'ai compilé avec la sfml sous codeblocks avec windows aujourd'hui et ça marchait. Enfin bref, j'ai donc mon .exe mais en passant sous windows ... J'aurais aimé faire ça depuis mon cher Ubuntu mais bon ...

[koala01]

Salut,

J'avais déjà essayé et il m'avait mis cette erreur:

/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/libstdc++.a(stubs.o):(.text+0x160): multiple definition of `_powf'
/tmp/ccbLh5RD.o:Brain.cpp:(.text$powf[_powf]+0x0)first defined here
collect2: ld returned 1 exit status

Et cela ne vient pas du fichier brain.cpp car j'ai compilé avec la sfml sous codeblocks avec windows aujourd'hui et ça marchait. Enfin bref, j'ai donc mon .exe mais en passant sous windows ... J'aurais aimé faire ça depuis mon cher Ubuntu mais bon ...

Pourtant, il te dit exactement ce qui cloche

Bon, d'accord, il faut un peu d'expérience pour comprendre, mais, essayons de faire cela dans l'ordre :

multiple definition of `_powf'

là, le monsieur te dit qu'il a trouvé plusieurs définitions correspondant à _powf.

/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/libstdc++.a(stubs.o).text+0x160)

Là, le monsieur t'indique qu'il s'en est rendu compte lorsqu'il a voulu faire joujou avec le contenu de libstdc++.a (en gros, avec la bibliothèque propre à C++), dans la partie de la bibliothèque qui correspond au fichier objet stubs.o, à peu près au niveau du 352ième équivalent caractère (parce que 0x160 en hexa correspond à 352 en décimale )

/tmp/ccbLh5RD.o:Brain.cpp.text$powf[_powf]+0x0)first defined here

Et là, il te dit qu'il a trouvé la première définition de ce symbole (_powf) au niveau du fichier Brain.cpp (dont je présumes que c'est un fichier à toi )

Il semblerait donc que tu aies essayé, d'une manière ou d'une autre, de définir une fonction proche de powf et que le compilateur ait généré le même symbole que celui qui se trouve dans la libstdc++ (sans doute parce que c'est le même nom et les mêmes arguments, à chaque fois dans l'espace de noms global )

Mais bon, comme cette explication n'arrive pas à me convaincre moi-même (pourquoi aurais tu voulu fournir ta propre implémentation de powf ) j'aurais tendance à dire qu'il y a, dans les fichiers que tu as inclus (ou dans ceux qui ont été inclus "en cascade") une définition de cette fonction dont un symbole préprocesseur (comme __INLINE__ ou quelque chose du genre) est, normalement défini pour représenter le mot clé inline, alors qu'il a été considéré comme un "symbole vide" au moment de la compilation.

Du coup, le compilateur n'ayant pas reconnu le symbole en question et ayant rencontré le code de ce qu'il a évalué comme étant le corps d'une fonction non inline aura généré le code binaire correspondant, sans le marquer comme étant "inline", et c'est sans doute ce qui a rendu l'éditeur de liens un peu fou

Je peux toujours me tromper, mais je ne serais pas étonné outre mesure si ton compilateur croisé s'était simplement "mélangé les pinceaux" entre les différents dossiers dans lesquels il doit aller chercher ses fichiers d'en-tête et s'il avait, "simplement" pris ceux utilisés par la version de Gcc que tu utilises en compilation "normale" (comprends: pour linux) au lieu de ceux qu'il devrait utiliser pour une compilation croisée.

A vrai dire, je suis confronté à un problème à peu près similaire pour l'instant en essayant d'installer une compilation perso de Gcc-4.8.1 sous xubuntu (qui travaille encore avec une version 4.7.xx) et qui s'obstine à n'utiliser que les en-tête de la version 4.7

Avec comme résultat le fait que certaines fonctionnalités de C++11 ne sont pas encore disponibles (la fonction membre emplace pour les std::map, par exemple)

[Kaamui]

Pourquoi utiliser le compilateur C s'il fait du Cpp ?

Parce que j'ai trouvé une source sur le net (ici) qui contournait le problème comme ceci. Je voulais donc savoir s'il s'agissait de la même raison, et j'aurais pu renvoyer un semblant d'explication en plus de la source, rejoignant ainsi Koala01 qui a encore une fois eu le nez extrêmement fin . En utilisant libstdc au lieu de libstdc++ on évite de rencontrer le problème de la deuxième définition de powf.

Je pense que ton problème vient des conventions de nommage des methodes dans la DLL.

Il faut surement retravailler la Dll pour que les nom des fonctions soient dans la bonne convention.
=> http://www.mingw.org/wiki/CreateImportLibraries

Pourquoi faire simple quand on peut faire compliqué... je ne penses pas que la solution à un problème de linkage soit de "retravailler" les dlls de la SFML.. Koala01 semble avoir trouvé la bonne explication, le compilateur se mélange.

Y'a pas d'encodage propre Microsoft, mais des conventions de nommage différentes que l'on peut choisir sous windows.

Ok.

[gnto]

Parce que j'ai trouvé une source sur le net (ici) qui contournait le problème comme ceci.

Quitte a passer encore une fois pour un extrémiste, je résonne en terme de contrainte. Je ne connais pas toutes les contraintes mais changer de techno parce qu'on ne comprend pas ce qui se passe est plus couteux en terme de temps que de chercher la vérité (selon moi et je peux me tromper). Après s'il y a du temps pourquoi pas.

Pourquoi faire simple quand on peut faire compliqué... je ne penses pas que la solution à un problème de linkage soit de "retravailler" les dlls de la SFML.

Ici je parlais des "undefined reference to `__imp___ZN2sf5Mouse15isButtonPressedENS0_6ButtonE'" et ca c'était avant de corriger la ligne de commande GCC.
Je suis intervenu car j'ai déjà rencontré des problèmes sous mingw sur des dll compiler avec MSVC et avec une convention stdcall ou cdecl. Mais le problème n'est pas la car la commande n'était pas la bonne et je suis allé trop vite en besogne.

[42toto]

Merci encore une fois de m'avoir aidé, et surtout koala, tu m'as bien éclairé =)

[germinolegrand]

Et simplement utiliser des binaires compilés par MinGW des fois ?