Petit problème avec gcc - Page 1

J'ai compilé un de mes programmes avec gcc, qui contient un include de 96 ko.

Quand je veux lancer la rom il ne se passe rien.
Je crois que ça vient de la taille de l'include, parceque quand il est plus petit 70 ko, ça marche nickel.

Comment cela se fait-il, et y a t-il une limitation de taille pour les inludes?
Et comment faire pour que ça marche (parceque j'en ai beson moi des autres ko)?

Je ne pense pas que la taille de l'include soit le problème. Il doit plutôt y avoir une erreur dans la partie que tu as supprimée pour réduire la taille.

Ce qu'il ya c'est que même avec la deuxième partie la compilation se passe sans problème: gcc ne m'indique aucune erreur.
Par contre c'est quand je lance ma rom qu'il ne se passe rien..

J'ai d'ailleurs essayé d'inclure cette deuxième partie dans un autre programme: ça marche trés bien.
Par contre quand je copie les deux parties l'une à la suite ça me fait le problème.

Je comprends vraiment pas ce qui se passe.

J'ai enfin trouvé.
Je pense qu'il s'est passé ça: (j'en suit pas tout à fait sur, merci de m'éclairer si des choses sont fausses)

En fait mon includes définissait plusieurs assez gros tableaux, qui devaient se mettre en mémoire ou sont entreposé les données non modifiables (game rom).
Seulement pour cela il faut déclarer les tableaux comme étant des entitités non modifiable (avec const).
J'avais oubliés const ce qui fait que les tableaus allaient en mémoire de travail (work ram) trop petite pour loger tout: d'où le bug.

-

Mon gcc je l'ai télécharger à partir du tuto d'edorul's, je crois.

Par contre pour ce qui est de ma bibliothèques GbaTiles elle utilise les fonctions cosinus et sinus de ma bibliothèque GbaMath.
Il faut surtout pas déclarer d'autre bibliothèques comme math.h qui définissent des fonctions cos() et sin(), car celles de GbaMath sont totalement différentes. (elles travaillent en décalage et sont issues de tableaux pour une meilleur rapidité et une meilleur précision).

Je crois que le plus simple sera que je renomme ces fonctions pour éviter les conflits avec d'autres bibliothèques

-

T'utilise pas GbaTiles ici?

Par contre ton compilateur il donne des undifined refernce à des variables qui ne se trouvent pas dans ta source, c'est bizarre.

Moi ça m'ai déjà arrivé (un trux dans le style) il suffisait d'effacer tous les fichiers créer par la compilation (main.o,main.s,makedepend,...), ensuite tu relance la compilation et ça marchait.

-

Je compend vraiment pas ce qui se passe.

Quels sont tes includes?

Orion_ a écrit :

/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:25: undefined reference to `__floatsisf'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:26: undefined reference to `__floatsisf'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:29: undefined reference to `__mulsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:29: undefined reference to `__mulsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:29: undefined reference to `__addsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:29: undefined reference to `__extendsfdf2'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:31: undefined reference to `__divsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:34: undefined reference to `__floatsisf'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:34: undefined reference to `__mulsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:35: undefined reference to `__mulsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:38: undefined reference to `__floatsisf'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:38: undefined reference to `__addsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:38: undefined reference to `__fixsfsi'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:39: undefined reference to `__floatsisf'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:39: undefined reference to `__addsf3'
/cygdrive/c/Prog/GBA/Develop/My/RadialBlur/Radial.c:39: undefined reference to `__fixsfsi'

Ce sont des fonctions utilisées en interne par GCC, qui devraient se trouver dans libgcc.a, et que GCC est censé linker automatiquement.

Ah oui, mais ce n'est pas malin d'appeler ld à la main.

Bon, essaye de rajouter libgcc.a là:
C:ProgGBADevelopMyRadialBlur>ld -L C:devkitadvarm-agb-elflib -Ttext 0x08000000 -Tdata=0x03000000 -o Radial.elf crt0.o Radial.o libgcc.a -lc

ah kevin est là on est sauvé...
Qu'entends tu part appeler ld à la main

-

mat
a écrit : ah kevin est là on est sauvé...

Qu'entends tu part appeler ld à la main

Appeler ld directement plutôt que de laisser GCC le faire. La méthode standard de compiler le projet est la suivante:
gcc -I C:devkitadvarm-agb-elfinclude -o Radial.elf -g -O2 -mthumb-interwork -save-temps -fverbose-asm -Wl,-L,C:devkitadvarm-agb-elflib,-Ttext 0x08000000,-Tdata=0x03000000 Radial.c
Mais je ne suis pas sûr que ça fonctionne correctement avec DevKit Advance (à vérifier). Ça dépend de s'ils ont configuré GCC correctement ou non.

Orion_
a écrit : merci kevin, sa marche nikel maintenant

Heureusement qu'il y a un expert de GCC ici. On se croirait sur la mailing list gcc-help parfois ici et dans la partie programmation GP32. Ça montre aussi le travail qu'on a fait pour faciliter l'utilisation de GCC dans TIGCC, vu qu'il y a rarement des questions de ce genre dans la partie TI.

Il est clair que gcc est vraiment trop pratique.
Il évite tous les ennui avec gcc, permat de compiler sans se préocuper de rien.
C'est une merveille.
J'aurais bien voulu faire un truc pareil pour gba mais j'ai pas vraiment les notions nécessaire . Peut-être dans un ou deux quand je serais en iut info.

-