[Tutoriel] Installation manuelle de GCC (et du fxSDK)
Posté le 31/05/2014 17:02
Parmi les compilateurs C/C++ modernes de premier plan (LLVM, GCC, MSVC...), GCC est le seul à avoir un backend SuperH, ie. capable de générer des add-ins pour les calculatrices CASIO. Dans ce tutoriel, on va voir comment compiler GCC à la main. J'y mentionne également par le symbole
les étapes supplémentaires nécessaires pour installer le fxSDK tout entier à la main.
Ce tutoriel était initialement utilisé pour toutes les installation de GCC pour la calculatrice, mais il y a maintenant des méthodes automatiques via le dépôt
sh-elf-gcc, via
MiddleArch ou même l'installation complète du fxSDK avec
GiteaPC. Le texte ci-dessous est donc destiné à des personnes relativement expérimentées avec le terminal et les processus classiques de compilation, et spécifiquement à ceux qui voudraient tester des configurations inhabituelles.
Pour relire l'ancien tutoriel, voir sur la forge Gitea.
Ce tutoriel est écrit pour Linux mais vous pouvez le suivre sous Windows 10 en utilisant
WSL qui vous donnera accès à Ubuntu.
1. Présentation du processus
Dans ce tutoriel, on va compiler plusieurs logiciels. Côté compilateur, d'abord
binutils, une suite de programmes qui gère l'assembleur, les fichiers objets, les bibliothèques, et l'édition des liens ; puis
GCC, le compilateur C/C++ en lui-même.
Ensuite on va faire un détour par le fxSDK pour installer la bibliothèque mathématique et la bibliothèque standard C qui sont nécessaires pour avoir accès à la totalité du langage C.
On reviendra alors vers GCC, puisqu'une fois la lib standard C installée on peut compiler la bibliothèque standard C++, qui est là aussi nécessaire pour avoir accès à la totalité du langage C++.
Enfin on pourra finir l'installation du fxSDK avec gint et d'autres bibliothèques.
[fxSDK] Commencez par installer le dépôt
fxsdk, qui fournit la sysroot dans laquelle on va installer le compilateur. C'est un
cmake/
make classique.
2. Installation des dépendances
Nos calculatrices utilisent des processeurs de la famille SuperH, on ne peut donc pas utiliser le même compilateur C que quand on programme pour l'ordinateur. On va utiliser un
cross-compilateur qui ne s'appelera pas
gcc mais
sh-elf-gcc, attention à ne pas confondre !
Téléchargez la dernière version de binutils (
téléchargement ici) ainsi que la dernière version de GCC (
téléchargement ici). En cas d'erreur insondable, vous pourrez toujours tenter d'autres versions plus tard.
Attention : Si votre GCC système est en version 12.1 ou 12.2 (tapez
gcc -v pour le déterminer), vous devez prendre GCC 11.1 pour la calculatrice à cause de
ce bug de GCC pour x86_64.
Bien sûr GCC est un logiciel complexe avec pas mal de dépendances. Voici de quoi les installer :
# Pour Debian, Ubuntu, Mint, WSL pour Windows, et autres dérivés de Debian :
% sudo apt install libmpfr-dev libmpc-dev libgmp-dev libpng-dev libppl-dev flex g++ git texinfo
# Pour Arch Linux, Manjaro, et autres dérivés de Arch :
% sudo pacman -S mpfr libmpc gmp libpng ppl flex gcc git texinfo
- MPFR : calcul flottant à précision arbitraire
- MPC : calcul complexe à précision arbitraire
- GMP : arithmétique entière multi-précision
- libPNG : manipulations d'images PNG
- PPL : optimisation polyhédrique (optimisation magique)
- flex : générateur d'analyseurs lexicaux
- g++ : compilateur C++ pour votre système
- git : gestionnaire de versions
- texinfo : générateur de documentation formatée
3. Préparation de l'environnement de compilation
Le compilateur et toutes les bibliothèques pour la calculatrice vont être installées dans un même dossier. Si vous utilisez le fxSDK, ce dossier est pré-choisi et la commande
fxsdk path sysroot vous l'affiche. Sinon vous pouvez aller où vous voulez, mais restez dans votre dossier personnel.
% export PREFIX="$(fxsdk path sysroot)"
# Exemple de dossier hors fxSDK :
# export PREFIX="$HOME/opt/sh-elf-2.39-11.1.0"
% mkdir -p $PREFIX
Assurez-vous que
$PREFIX/bin est dans votre PATH. Extrayez le contenu des archives que vous avez téléchargées dans un dossier temporaire, et créez deux répertoires
build-binutils et
build-gcc.
% tar -xJf binutils-2.39.tar.xz
% tar -xJf gcc-11.1.0.tar.xz
% mkdir build-binutils build-gcc
On va ensuite appliquer quelques patchs. On va d'abord toucher un fichier de binutils pour éviter la régénération d'un parser avec bison qui ne marche plus depuis longtemps :
% touch binutils-2.39/intl/plural.c
Si vous utilisez GCC 11.1 (et sans doute quelques versions d'avant), téléchargez de plus
ce patch qui désactive des tests de configuration inutilement aggressifs dans la lib C++ et appliquez-le :
% patch -u -N -p0 < gcc-11.1.0-libstdc++-v3-skip-dlopen.patch
4. Compilation de binutils
La compilation de binutils est un configure/make classique. Les options qu'on utilise sont :
- --prefix pour indiquer le dossier d'installation final.
- --target="sh3eb-elf" pour spécifier qu'on veut un cross-compilateur pour SuperH.
- --with-multilib-list="m3,m4-nofpu" indique plus précisément qu'on veut une variante pour SH3 et une pour SH4 sans FPU.
- --program-prefix="sh-elf-" renomme le compilateur de sh3eb-elf-gcc à sh-elf-gcc vu qu'on a aussi le SH3.
Il n'y a pas beaucoup d'autres options intéressantes, mais vous pouvez les voir toutes avec
configure --help.
% cd build-binutils
% ../binutils-2.39/configure --prefix="$PREFIX" --target="sh3eb-elf" --with-multilib-list="m3,m4-nofpu" --program-prefix="sh-elf-"
Une fois que tout est configuré, il n'y a plus qu'à compiler et à installer. Normalement ça va assez vite, comptez quelques minutes.
% make -j4
% make install-strip
Les exécutables de
binutils ont dû apparaître dans
$PREFIX/bin Essayez
sh-elf-ld --version qui doit vous renvoyer la version de binutils (ici 2.39).
5. Compilation de gcc et de libgcc
Ensuite c'est pareil mais pour GCC. En plus des options précédentes, on indique :
- --enable-languages="c,c++" qui spécifie les compilateurs qu'on veut. Si vous voulez expérimenter avec d'autres langages notamment Ada, D, Go ou Fortran, c'est là qu'il faut commencer !
- --without-headers qui indique essentiellement qu'on veut un cross-compilateur.
- --enable-clocale="generic" qui simplifie le module <locale> de la lib C++.
- --enable-libstdcxx-allocator qui fait de même avec les allocateurs mémoire.
- --disable-threads qui désactive le threading (qu'on n'a pas).
- --disable-libstdcxx-verbose qui élimine des logs dans la lib C++.
- --enable-cxx-flags="-fno-exceptions" qui désactive les exceptions durant la compilation de la lib C++.
Voyez
le guide de configuration pour toutes les options utiles.
% cd "$PREFIX/build-gcc"
% ../gcc-11.1.0/configure --prefix="$PREFIX" --target="sh3eb-elf" --with-multilib-list="m3,m4-nofpu" --enable-languages="c,c++" --without-headers --program-prefix="sh-elf-" --enable-clocale="generic" --enable-libstdcxx-allocator --disable-threads --disable-libstdcxx-verbose --enable-cxx-flags="-fno-exceptions
Cette fois la compilation occupera entre 10 et 30 minutes... ou 5/6 heures sur un vieux Raspberry Pi.
% make -j4 all-gcc all-target-libgcc
% make install-strip-gcc install-strip-target-libgcc
Avec ça vous devez pouvoir taper
sh-elf-gcc -v et la version et les options de compilation.
[fxSDK] C'est le moment d'installer
OpenLibm, avec
make.
[fxSDK] Installez aussi la lib C,
fxlibc, un autre
cmake/
make classique.
6. Compilation de libstdc++
On peut maintenant revenir dans le dossier de compilation de GCC et compiler des libs plus évoluées, comme la lib C++. Si vous testez d'autres langages (par exemple D) c'est le moment de compiler les libs qui vont avec (libphobos), ou même de compiler libssl, libiberty, etc. selon vos goûts.
% make -j4 all-target-libstdc++-v3
% make install-strip-target-libstdc++-v3
Et voilà, la toolchain est complète. Si vous manquez d'espace disque vous pouvez supprimez les archives, dossiers de sources, et dossiers de build de binutils et GCC.
Vous pouvez aussi installer
gdb dans la même veine que binutils pour pouvoir debugger les add-ins à distance.
[fxSDK] Installez maintenant
gint, et les autres libs qui vous plaisent (eg. libprof, zlib, etc).
Et voilà, vous avez un compilateur C/C++ complet voire un SDK complet pour programmer des add-ins.
Fichier joint
Citer : Posté le 21/02/2018 13:55 | #
Tu as déclaré la fonction IsKeyUp() comme prenant un int en argument, mais tu l'as implémentée comme prenant un key_t. Les deux sont équivalents, donc prends n'importe lequel, mais utilise-en un seul.
Citer : Posté le 21/02/2018 14:05 | #
Ah oui merci j'avais pas vu
Ça compile ! o/
Sympa le nouvel ecran pour les Erreurs Mémoires
Citer : Posté le 21/02/2018 14:48 | #
Nouvel écran ? Cette fonctionnalité est la raison pour laquelle memory a été inventée en premier lieu ! Ça permet au gens de lire un fichier en une seule ligne en jetant les erreurs à la figure de l'utilisateur au lieu de les gérer eux-mêmes.
Tu vois, quand je dis qu'il ne faut pas utiliser cette lib...
Citer : Posté le 23/05/2018 21:38 | #
Ah voilà, j'ai réussi à retrouver ce topic.
L'outil marche-t-il aussi pour fx-CG / Graph 90+E ?
Merci.
Citer : Posté le 23/05/2018 21:42 | #
comme je te l'ai mis dans le topic sur la shout c'est plutôt par ici pour la g90 : https://www.planet-casio.com/Fr/forums/topic15023-1-Prizm-(fx-CG10-20),-G90-et-fx-CG50,-environnement-de-develop.html
Citer : Posté le 23/05/2018 21:57 | #
Merci @Suruq game.
Citer : Posté le 24/05/2018 04:30 | #
Le g1a-wrapper comporte un problème, il ne respecte pas le checksum utilisé par le SDK : le short à 0x16-0x17 est la somme de 8 shorts à partir de 0x300 (merci simlo parce que j'aurais jamais trouvé tout seul).
Du coup j'ai fait un petit script python pour corriger ça :
addinPath = sys.argv[1]
a = open(addinPath, "r+b")
s = a.read()
str = s[0x300:0x310]
sum = 0
for i in range(8):
sum += 256*str[2*i]+str[2*i+1]
sum %= 0x10000
byte1 = 255-(sum//256)
byte2 = 255-(sum%256)
array = bytearray(s)
array[0x16] = byte1
array[0x17] = byte2
t = bytes(array)
a.seek(0)
a.write(t)
a.close()
Il suffit de l'appeler avec "g1a-wrapper-fix.py addin.g1a".
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/05/2018 06:30 | #
Ooh, pas mal ! Je n'avais pas trouvé le problème quand j'avais cherché dans la doc
Je garde cet onglet ouvert et je commit un fix dès que je peux. Ça évitera le script Python.
Citer : Posté le 23/07/2018 10:22 | #
Avec binutils 2.30 et gcc 7.3.0 :
# define fputs(String, Stream) fputs_unlocked (String, Stream)
^
(et 3424 erreurs similaires, en bref : il trouve pas fputs_unlocked).
Une idée ? Je trouve rien sur google.
Ajouté le 27/07/2018 à 13:48 :
Bon, toutes les erreurs que j'avais venaient du header system.h, plus précisément de ce if :
# undef fputs
# define fputs(String, Stream) fputs_unlocked (String, Stream)
# if defined (HAVE_DECL_FPUTS_UNLOCKED) && !HAVE_DECL_FPUTS_UNLOCKED
extern int fputs_unlocked (const char *, FILE *);
# endif
# endif
On commente le ifdef et hop tout compile
Du coup lephé, tu as corrigé le problème du g1a-wrapper ou non ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 31/07/2018 17:11 | #
L'erreur est bizarre ; ta solution encore plus, mais bon.
Oui, merci de ta patience, j'ai corrigé. J'ai fait un test sur l'add-in gint et ça a donné le bon résultat.
Je ne sais pas trop ce qui est supposé se passer s'il y a moins que 0x110 octets dans le fichier source, j'ai fait comme s'il y avait des zéros ensuite.
Dis-moi si ça donne ce que tu veux
Citer : Posté le 31/07/2018 18:26 | #
Pour l'histoire du checksum : c'est bizarre, même l'add-in officiel GEOMETRY.g1a ne respecte pas ce checksum. Tu as la source de ton information ?
00000200 4f 22 60 53 d3 08 7f f8 2f 42 43 0b 81 f2 e6 01 |O"`S..../BC.....|
00000210
cake@66 :: tests/addins » hexdump -C -s 0x16 -n 2 GEOMETRY.g1a
00000016 00 00 |..|
00000018
cake@66 :: tests/addins » python -c "print(hex((0x4f + 0x22 + 0x60 + 0x53 + 0xd3 + 0x08 + 0x7f + 0xf8 + 0x2f + 0x42 + 0x43 + 0x0b + 0x81 + 0xf2 + 0xe6 + 0x01) % 0x10000 ))"
0x68f
cake@66 :: tests/addins » python -c "print(hex((0x4f22 + 0x6053 + 0xd308 + 0x7ff8 + 0x2f42 + 0x430b + 0x81f2 + 0xe601) % 0x10000))"
0xdcb5
cake@66 :: tests/addins » python -c "print(hex((0x224f + 0x5360 + 0x08d3 + 0xf87f + 0x422f + 0x0b43 + 0xf281 + 0x01e6) % 0x10000))"
0xb8da
Sinon, techniquement, c'est à la libc de définir fputs_unlocked() (fait partie de la bibliothèque standard version async, mais seulement la version GNU a priori, c'est même pas standard ><), mais aucune bibliothèque C disponible pour la calculatrice ne définit cette fonction actuellement (ça requiert du hosted, pas du freestanding)… x)
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 31/07/2018 19:28 | #
Ouaip, et geometry.g1a ne tourne pas sur le sdk
Fais le test sur n'importe quel addin compilé avec le sdk et tu verras que c'est bon (la source c'est simlo).
Ajouté le 11/08/2018 à 11:34 :
Lorsque j'utilise la fonction pow(), elle me retourne toujours -0.00000, une idée de pourquoi ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 11/08/2018 11:48 | #
Très honnêtement, pas la moindre. '-'
J'ai ajouté l'option -mrenesas au tuto.
Citer : Posté le 12/08/2018 11:04 | #
De ton côté, pow() retourne des résultats normaux ou pas ? (que je voie si c'est mon environnement ou pas)
Aussi, y'a des side effects : si je vire mes breakpoints, pow() crashe au lieu de retourner -0.0000 (c'est la cause de l'erreur que j'ai avec les doubles dans micropython).
Ajouté le 12/08/2018 à 11:59 :
Les fonctions toupper() et tolower() retournent une erreur "undefined reference to '___locale_ctype_ptr'" (j'ai réimplémenté les fonctions en attendant).
Ajouté le 12/08/2018 à 12:47 :
Le sprintf() me fait des erreurs, lorsque j'exécute un sprintf ça attend genre 2-3 secondes puis hop une TLB error. (je vais devoir réimplémenter combien de fonctions
Ajouté le 12/08/2018 à 13:43 :
J'ai testé 2 implémentations de sprintf (https://github.com/cjlano/tinyprintf/ et https://github.com/mpaland/printf), les 2 me font des NPE... pourtant mon code il est pas compliqué :
tfp_sprintf(str, "%d", 1);
locate(1,7); Print(str);
GetKey(&key);
Une idée ? Je suis bloqué là :/
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 12/08/2018 14:32 | #
Réimplémente, te pose pas de questions.
Ouh là, pas normal du tout ça. Ne réimplémente pas printf() hein, tu t'imagines pas la quantité de travail que c'est '-'
Restons sur le tinyprintf par exemple. NPE, c'est quoi ? SysERROR ? Nonexisting memory ? EBR ? Erreur de compilation ?
L'histoire de -mrenesas, c'est important quand tu as des fonctions à arguments variadiques, comme sprintf(). As-tu bien fait attention à compiler le code de sprintf() et le code qui l'appelle avec la même convention (c'est-à-dire soit -mrenesas pour les deux, soit rien pour les deux) ?
Citer : Posté le 12/08/2018 14:59 | #
Une erreur de ce style :
Dans le makefile j'utilise -mrenesas dans les CFLAGS et LDFLAGS, tout est compilé avec ça donc normalement c'est la même convention.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 12/08/2018 18:19 | #
Eh, accéder à un pointeur null ça marche pas
Citer : Posté le 12/08/2018 18:32 | #
Pour le tinyprintf, la NPE vient de tfp_sprintf :
{
va_list ap;
int retval;
int key;
va_start(ap, format);
retval = tfp_vsprintf(str, format, ap);
va_end(ap);
return retval;
}
qui appelle tfp_vsprintf:
{
int key;
struct _vsprintf_putcf_data data;
data.dest = str;
data.num_chars = 0;
tfp_format(&data, _vsprintf_putcf, format, ap);
data.dest[data.num_chars] = '\0';
return data.num_chars;
}
qui appelle tfp_format(void *putp, putcf putf, const char *fmt, va_list va) et qui plante sur ça :
Pourquoi le fmt (qui est l'adresse de mon string, "%d") est nul ?
(après, si c'est un problème avec les varargs, c'est sûr que toutes les implémentations vont bugger)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 12/08/2018 21:16 | # |
Fichier joint
J'ai testé de mon côté ; le printf() de fxlib ne coopère pas très facilement. Je n'ai pas réussi à le faire marcher, même sur des cas triviaux où il n'y a pas d'arguments variables. À rechercher.
J'ai ensuite essayé tinyprintf et ça a marché comme sur des roulettes. Je te joins un exemple de projet compilable qui marche sans problème du premier coup, pour tester.
Ajouté le 12/08/2018 à 21:20 :
Après un test très rapide, aucun problème avec le pow() de fxlib. N'oublie pas que c'est double pow(double x, double y).
double sixteen = pow(2., 4.);
tfp_sprintf(str, "%d = 16", (int)sixteen); /* 16 = 16 */
Citer : Posté le 12/08/2018 23:18 | #
En effet, c'est mon makefile qui fait merder donc (j'ai remplacé mon libfx.a, addin.ld et crt0.s par les tiens, ça fait toujours la même erreur).
Si tu veux tester de ton côté, j'ai mis tout ça sur github : https://github.com/Zezombye/casiopy (dans ports/minimal/, exécute build.sh)
Dis si tu trouves le problème, parce qu'à première vue je vois rien dans mon makefile qui pourrait causer l'erreur (j'ai toutes tes options).
Ajouté le 12/08/2018 à 23:20 :
Et en effet, le pow marche aussi sur ton programme... y'a des trucs chelous dans mon makefile.
(utiliser des doubles ou pas ça change rien : pow(2,4) marche aussi)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 13/08/2018 08:59 | #
En l'occurrence gcc fait la conversion automatique pour toi parce que j'ai donné le prototype. Si tu lui envoyais des int ça renverrait toujours 1
Ah, j'y crois pas. Tu as mis des fichiers sources dans les options du linker ?
S'il te plaît, va lire un tutoriel sur comment on compile des gros programmes C en plusieurs étapes, ça te sauvera de te planter de nouveau comme ça.
Là j'ai pas essayé mais j'ai une idée d'où ça foire.