Cross compilation avec SDL Résolu/Fermé

Question

Bonjour,

J'ai créer une application en SDL sous Linux et j'aimerais la cross compiler pour qu'elle fonctionne aussi sous Windows.
J'ai réussi à cross compiler une application qui n'utilise que les bibliothèques standards comme stdio et stdlib mais je ne sais pas du tout comment faire avec la SDL.
Je vous remercie de votre aide.

Char Snipeur · Answer

il faut récupérer la SDL de windows. Comme il s'agit d'application graphique, le code source de SDL est différent entre les deux.

Pico51 · Answer

Donc je télécharge SDL-devel-1.2.13-mingw32.tar.gz (Mingw32) sur le site de la SDL et ensuite ?

Char Snipeur · Answer

tu compiles :D
sérieusement, je ne vois pas où est le problème.
Si tu n'as que les sources, tu dézip, tu lis les instructions de compilation, et tu les met en pratique.
Ensuite, il ne reste plus qu'a compilé ton programme comme sous linux. Bref, rien de mystérieux !

Pico51 · Answer

J'ai donc téléchargé SDL-devel-1.2.13-mingw32.tar.gz (Mingw32) et je lis le fichier install :
1.  Run './configure; make; make install'
Il n'y a pas de fichier configure ! Qu'est-ce que je fais alors ?

Char Snipeur · Answer

si il y a un makefile, tente le make.
par contre, tu as gcc du pack mingw ou cygwin ? J'ai remarqué qu'il y avait quelques différences entre les deux.

Pico51 · Answer

J'ai fait un make cross et cela m'a créé un dossier /usr/local/cross-tools/i386-mingw32/ et dedans, cela m'a installé les bibliothèques de la SDL.
Mais maintenant, comment je compile ? Et pourquoi est-ce dans un dossier i386-... alors que d'habitude, quand je cross compile sans la SDL, je suis dans le dossier /usr/i586-mingw32msvc/ et que j'utilise i586-mingw32msvc-gcc pour compiler ?

Char Snipeur · Answer

"make cross" ?? si tu le dit.
pour i386, j'en sais foutre rien, peut être que le portage Win est moins avancé sur les spec des cpu récent ?
"Comment je compile ?"
ba tu compiles en spécifiant la bonne bibliothèque. Je viens juste de comprendre que tu veux compiler pour windows sous Linux !
Je n'ai aucune expérience là dedans, mais si tu l'as déjà fait avec stdio, tu peu le faire avec SDL.
tu fait -lSDL, mais à la place de -L/usr/local/SDL/lib, tu fait -L/usr/local/cross-tools/i386-mingw32/lib
je pense...

Pico51 · Answer

J'ai toujours cette erreur quand je compile :
In file included from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL_main.h:26,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL.h:28,
                 from main.c:3:
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL_stdinc.h:72:20: error: iconv.h: Aucun fichier ou dossier de ce type
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL_stdinc.h:169:22: error: alloca.h: Aucun fichier ou dossier de ce type
In file included from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL_main.h:26,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL.h:28,
                 from main.c:3:
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/SDL/SDL_stdinc.h:579: error: expected ‘)’ before ‘cd’

Char Snipeur · Answer

il ne trouve pas iconv.h
vérifie que tu l'as bien sur ton disque, et donne lui le chemin.
Si tu ne l'as pas, c'est que SDL semble mal installer ou alors que c'est un en tête windows qui te manque.

Pico51 · Answer

Oui, je n'avais pas tout les headers !
Maintenant, quand je compile, tout se passe bien mais lorsque j'exécute avec wine, j'obtiens les erreurs suivantes :
$ wine brik.exe 
fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0080: stub!
fixme:keyboard:X11DRV_LoadKeyboardLayout L"040c040c", 0001: stub!
Et je vois le programme s'afficher puis disparaître très rapidement.
Pourquoi ? Et qu'est-ce que je dois faire ?

Char Snipeur · Answer

J'ai eu le même problème avec wine, il me disait de recompiler wine.
Je te conseil de tester avec un PC windows, là tu cumul les ennuies : est-ce que ça viens de wine ou de ta compilation ?? Si le programme s'affiche c'est au moins une bonne nouvelle. Je pencherai pour un problème wine.

Pico51 · Answer

Bah, une fois compilé, ça ne marchait pas sur wine alors j'ai testé sur Windows mais il m'arrive la même chose, le programme s'affiche et disparaît immédiatement.

Char Snipeur · Answer

lance le depuis une console voir si il y a des messages d'erreur. Sinon, utilise le debugueur, relève le code de sortie de l'erreur et réfère toi au manuel.

Pico51 · Answer

Sous Windows, quand je le lance depuis la console, je n'ai aucun message d'erreur mais la fenêtre s'ouvre et se referme quand même :
>brik.exe
(La fenêtre s'ouvre et se referme)
>

Je viens d'utiliser le débugger avec casiment toutes les options possibles (-g, -g3, -gstabs, -gstabs+, ...) et je n'ai jamais eu de message d'erreur.

Char Snipeur · Answer

lance ton programme dans la console, peut être avec "start" afin de le bloquer, et regarde le code de retour avec
echo %ERRORLEVEL%
Sinon, il faut débugguer à coup de "printf" le long du programme.
Si ton application est graphique, compile tu avec l'option -mwindows ? Sinon, comme le suggère wine, il est possible qu'il y ai un problème entre la SDL et windows au niveau de la gestion du clavier. Bien que le message de wine me soit très obscure. (recherche sur internet d'où peu venir cette erreur)

Pico51 · Answer

Quand j'utilise ou non start, j'obtiens un %ERRORLEVEL% = 3 ! Je ne sais pas ce que ça veut dire mais bon !
J'ai déjà essayé de le débugger avec printf() mais le premier que j'avais placé avant mes déclarations n'est même pas apparu ce qui voudrait dire que l'erreur a lieu avant le main().
Non, je n'utilise pas l'option -mwindows (car je ne sais pas à quoi elle sert) mais je vais essayé.
J'ai également recherché sur Internet que voulait dire l'erreur de Wine mais je n'ai rien trouvé.

Edit : il se passe toujours la même chose même en ajoutant -mwindows.

Char Snipeur · Answer

l'option -mwindows (ou -mwindow, je ne suis pas certain) permet de faire une programme windows qui ouvre ou non un fenêtre console.
Une fois que tu as le code erreur, il faut savoir à quoi il correspond. Il est fort possible que ça vienne de la SDL donc cherche dans le code source des exit() ou abort() qui enverrai 3 (là bonne chance, car en général on met des variables, ou pire, des macros)
Mais si même la première ligne du main n'est pas exécuter, c'est bizarre. J'ai ce problème sous Linux avec pthread lorsque je lie sans spécifier -lpthread, car il arrive à lier avec la bib standard, mais ça cause une erreur lors de l'exécution. J'ai aussi ce problème des fois avec QT, mais là je reconstruit tout le projet et ça va mieux.
Puisque tu as windows sous la main, tu peux aussi tenter une compilation directement dessus, avec mingw32.

Pico51 · Answer

Donc, si l'erreur vient de la SDL, la variable qui vaut 3 dans SDL_error.h est SDL_EFSEEK. Pour le moment, ça ne m'aide pas beaucoup !
Mais je me demande si on peut utiliser un débugger en même temps que l'on exécute le programme de manière "pas à pas"; je ne sais pas du tout me servir des débugger (d'habitude, ça marche !).
Et si je comprend bien, j'ai plus trop d'autres choix pour faire marcher mon programme !!!

Edit : en fait, je ne sais pas pourquoi mon programme ne faisait pas marcher mes printf() mais en compilant sous Windows, j'ai trouvé que l'erreur se trouvait à la ligne :
rBalle.x = ecran->w / 2 - sBalle->w / 2;
A la suite de cela, j'ai une erreur qui renvoie 0x3.

Pico51 · Answer

Finalement, j'ai trouvé d'où venait le problème : c'était le fonction IMG_Load qui ne marchait pas car ... car ... car j'avais oublié ... une DLL !!!!!!!!!!!!

Enfin, merci beaucoup pour toute ton aide !!!

Malgré tout, pourquoi mon programme est-il beaucoup plus lent sur Vista ?

Char Snipeur · Answer

Erreur étrange, le manque de DLL... J'utilise peu les dll, en général Window t'alerte qu'elle manque.
Avec un peu de mauvaise fois, je dirai : "à cause de Vista qui est de la merde".
Est-ce que SDL est pleinement compatible Vista ? car il est possible que SDL ne prenne pas en compte les nouveauté et tourne en un mode dégradé. Test avec un bon vieux XP. Sinon, la compilation qui est moins optimiser ou une connerie du genre.

Pico51 · Answer

Non, c'est tout aussi lent sur XP mais je me demande si ce n'est pas due à une fuite de mémoire de mon programme bien que je me demande pourquoi ça ne ralentit pas sous Ubuntu.

Char Snipeur · Answer

D'après ce que j'ai lu sur le OOM killer de Linux, il est possible que la gestion optimiste de Linux sur la mémoire fasse que le programme va vite, et inversement sur Win, qui gère la mémoire différemment.
Utilise un profiler (gprof) pour voir où tu passe le plus de temps sous Win et sous Linux, tu pourra ensuite en tirer les conclusion (compilation avec l'option -q si je me souviens bien)
regarde là pour oom : https://linuxfr.org/forums/linux-redhat/posts/raisons-susceptibles-du-d%C3%A9clenchement-doom-killer  ;)

Pico51 · Answer

J'ai ajouté l'option -Q en compilant avec gcc puis avec i586-mingw32msvc-gcc et je vois que, avec gcc, ça prend plus de temps qu'avec mingw32 (2 ms secondes de plus, au total). Mais, je voudrais plutôt trouver où a lieu ma fuite de mémoire et j'aimerais savoir comment utiliser un compilateur avec gcc qui me dit, quand je le demande, la mémoire qui est allouée : par exemple, dans une fonction, je mets plusieurs breakpoint et à chaque fois, j'ai un message qui s'affiche avec la mémoire allouée ce qui me permet de savoir où se trouve le problème. Ou alors, il existe une fonction avec stdio.h ou stdlib.h qui permet de faire ça (je ne sais pas, je demande).

Char Snipeur · Answer

J'ai pas tout compris à tes histoires de gcc et mingw32. là tu me parle de temps de compilation.
En fait, ce n'est pas l'option -Q, mais -pg qu'il faut ajouter. Ensuite, tu exécute le programme et tu regarde la différence avec gprof grace au fichier qui est créé : "gmon.out".
une fuite de mémoire, si elle est différente sur Linux et Win, c'est que le problème est dans une bibliothèque, car ton programme est le même.

Pico51 · Answer

Sous Linux, j'ai compilé avec -pg et exécuter le programme mais je n'ai pas réussi à lire gmon.out avec gprof : j'obtiens une erreur : gmon.out n'est pas un exécutable.
Bref, j'ai tout de même trouvé d'où venait la fuite et je l'ai corrigée, j'ai compilé pour Windows et Linux mais j'obtiens des résultats étranges.
Sous Linux, la vitesse est normale et le programme utilise 3,4 Mio de mémoire vive.
Sous Windows XP, la vitesse est lente et le programme utilise 8,3 Mo de mémoire vive.
Et sous Vista, le programme fait planter tout le système !!!!
Pourquoi ces différences ???

Char Snipeur · Answer

Bon, déjà, fait un effort, lit la notice de gprof ! (man gprof) 
il faut lui donner le nom du programme, gmon.out ne se suffit pas à lui même.
Comme je t'ai dit, MS et Linux gère la mémoire de façon un peu différente, donc c'est normal d'avoir des différences.
Moi, j'ai remarque é que mes exécutable windiws était plus volumineux, selon la taille du .exe, ça peut expliquer la différence. Ensuite, les bibliothèques peuvent aussi être différentes, et programmer du graphique sous wi, c'est normalement plus compliqué, donc peut être plus couteux en mémoire.
Sur la vitesse, concentre toi sur gprof, selon que la perte de temps est global ou localiser, il faudra aviser.
là, c'est le contraire :
https://openclassrooms.com/forum/sujet/sdl-fluidite-28699

Tu mets bien -O3 sous windows lors de la compilation ?

Pico51 · Answer

Quand j'utilise, gprof pour Linux, ça marche bien mais avec Windows, gprof me dit bien combien de fois les fonctions ont été appelé mais tous les temps sont à 0.00 ms. J'ai voulu essayé de trouver les temps de chaque fonction à l'aide de GetTickCount() mais j'ai un problème à la compilation.
Je ne sais vraiment plus quoi faire.

Pico51 · Answer

J'ai finalement utilisé la fonction SDL_GetTicks() et je constate que sur XP, une de mes fonctions est 8 fois plus lente et sur Vista, 6 fois plus lente. Les autres fonctions sont trop rapide (< 1 ms) donc SDL_GetTicks n'est pas assez précis.
Cette fonction qui est plus lente contient une boucle et des SDL_BlitSurface. Cette fonction de la SDL serait plus lente sous Windows ?
Parce que si ce serait 1,5 fois plus lente, cela pourrait aller mais là, c'est catastrophique !!!

Char Snipeur · Answer

je penses que tu commence à cerner le problème. Il faut que tu trouve une astuce soi pour éviter d'utiliser cette fonction, soit pour améliorer ton algorithme.

Cross compilation avec SDL

29 réponses

Discussions similaires