[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 16/08/2018 14:59 | #
Je comprends pas pourquoi tu fais autant chier alors que si j'ai bien suivi, il suffit que tu foutes tes headers modifiés dans ton dépôt git et voilà. Non ?
Et pourquoi tu veux absolument pas le faire ? Sur ce point, je pense que Lephé est bien plus compétent, c'est quoi ta raison de ne pas l'écouter ? La flemme ? J'vous jure.
Citer : Posté le 16/08/2018 15:09 | #
Nan, lephé veut que je modifie les headers du sdk au lieu de prendre ceux de gcc, et moi je trouve que c'est inutile et de toute façon quand j'essaie de faire ça ça me fait des erreurs x)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 16/08/2018 15:18 | #
Je le répète une troisième fois... soyons sérieux, ce sera la dernière.
Ces headers ne sont pas fournis par GCC. Bordel.
Vu ce que tu as dans ton répertoire ce sont certainement des headers de newlib. Les fichiers fournis par GCC commencent quasiment tous par This file is part of GCC et comme par hasard, ces headers standards non.
Je n'ai pas les headers que tu utilises. Tu es le seul à les avoir.
Soit tu te décides à fournir des headers avec ton projet en reconnaissant que tu n'as pas le choix car on n'a pas de libc communautaire pour laquelle on puisse dire « compilez mon projet avec sh3eb-elf [lien] et cette libc [lien] », soit tu arrêtes d'emmerder les gens pour leur faire modifier leur environnement d'exécution avec les mains.
Ton avancement dans ce port de MicroPython est impressionnant, mais la mauvaise foi et le bidouillage que tu y mets le sont encore plus. Jusque-là tu n'as écouté ce que je te racontais que quand tu n'avais pas une solution plus sale et plus directe à appliquer, alors continue comme ça, mais debugge tout seul. C'est épuisant.
Citer : Posté le 16/08/2018 15:31 | #
Ah, donc tu veux juste que je mette les headers dans mon projet au lieu du dossier include de gcc ?
- Vu que c'est entre chevrons, ça va pas aller de toute façon les rechercher dans le dossier include ? (ou alors je remplace tous les chevrons par des guillemets, ça pourrait se faire)
- Comment je fais pour qu'il prenne le math.h du projet au lieu de celui du sh3eb-elf-gcc ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 16/08/2018 15:33 | #
Mais oui ! Tu ne peux pas supposer que la personne qui va compiler ton programme a déjà les headers. Moi je les ai pas. Ceux de mon système sont incompatibles. Comment je fais, pour compiler ? Bidouiller n'est pas une option.
- Comment je fais pour qu'il prenne le math.h du projet au lieu de celui du sh3eb-elf-gcc ?
Il suffit que tu ajoutes un -I ton_dossier, tu peux continuer à utiliser les chevrons. Il va toujours chercher les dans les dossiers notés avec -I avant les dossiers système.
Citer : Posté le 16/08/2018 17:05 | #
J'ai commit en mettant les headers dans le dossier include du projet
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 16/08/2018 21:39 | #
Abstraction faite du dépôt Git qui explose dans tous les sens (et je ne sais même pas qui est responsable pour le coup), ça compile.
Actuellement ça m'affiche a et ça SysERROR quand j'appuie sur une touche. Je peux avoir les détails sur où est le code que tu manipules en ce moment et un rappel des objectifs/problèmes ?
Citer : Posté le 16/08/2018 21:57 | #
(en assumant que tu testes sur sh3, bien sûr)
La SysError vient du tinyprintf. Dans le casiopy.c je teste le tinyprintf, puis le mpy_main. Tu peux donc commenter l'appel à tpf_sprintf sans problème.
Après, si tu tapes un nombre décimal dans l'interpréteur, tu auras des lettres (de débug), normalement ça crashe après "p".
Ajouté le 16/08/2018 à 22:14 :
Pour plus d'infos, le code d'entrée de l'interpréteur est dans lib/utils/pyexec.c (cherche "zezombye" ça te donnera la bonne fonction), et le code qui gère les nombres décimaux est dans py/parsenum.c.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 17/08/2018 16:35 | #
First up: props to your patience, Lephé!
Now as I see it, there is no universal libc for the sh3eb-elf arch, only some parts provided by fxlib, gint and others. For me personally that is a pity since I cannot really cross-compile libraries without libc.
Have there been efforts of porting an implementation (maybe newlib) to sh3eb-elf, yet? I have a project in mind which requires the use of big integers (GMP) for cryptographic calculations.
Citer : Posté le 17/08/2018 16:54 | #
Thanks!
You're right, a lot is still missing. I have some serious implementations of printf() except for floating-points, but nothing related to scanf(). Apart from that I think almost everything has been implemented.
gint should strive to have a standard library (in fact there is a libc.a in gint's Makefile) but for now I am focused on writing the kernel and the libc is still lacking a lot.
There has been very little efforts towards porting anything, to be honest. Cakeisalie5 has been interested in writing PC/calculator-compatible programs when he still actively developed his projects, but that's pretty much everything for the last 4/5 years. Most C programmers here are no experts.
There is some libc.a archive for fx-CG 10/20, @Nemhardy will know the details. I think it's a port of newlib, but the sources have been lost IIRC.
I expect a serious port of newlib to be successful, provided you have some knowledge of the calculator's system calls from fxlib. As for porting GMP, it would probably be easier. If you are interested into doing this, it would be of help for many ports, including Zezombye's MicroPython.
(As for me, I'd need some specific port or functions for gint, but I'll see in time.)
Ajouté le 17/08/2018 à 22:10 :
The fact that you linked to OSDev.org shows that you certainly know what you are doing. I'd really like to see what your project is like ;D
Citer : Posté le 18/08/2018 15:37 | #
Du coup Lephé tu en es où ? Dis si t'as besoin de plus de précisions ou si je dois modifier des trucs
Ajouté le 20/08/2018 à 07:53 :
double pow(double x, double y);
double sixteen = pow(2., 4.);
tfp_sprintf(str, "%d = 16", (int)sixteen); /* 16 = 16 */
Sauf que le compilo il optimise les appels à pow avec des valeurs littérales, donc ça ne prouve rien !
Pour bien tester il faudrait faire ça :
double sixteen = pow(two, 4.);
tfp_sprintf(str, "%d = 16", (int)sixteen); /* 16 = 16 */
Par contre, quand je rajoute le volatile, ça me fait une erreur de linkage :
J'avais la même erreur causée par la déclaration de mon tableau de bitmaps en int, je l'ai déclaré en static const int et j'ai plus l'erreur (et le sprintf remarche). Par contre le pow marche toujours pas du coup.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/08/2018 08:31 | #
Aha le con ! Très bien vu
double sixteen = pow(two, 4.);
tfp_sprintf(str, "%d = 16", (int)sixteen); /* 16 = 16 */
Tu n'es pas obligé de mettre le volatile pour le coup. Il suffit de faire une fonction dans un fichier externe.
Oui mais on s'en fout ça, c'est une fausse erreur. Ajoute *(.eh_frame) dans la liste /DISCARD/ à la fin de ton linker script.
En int ? Ça nécessite une initialisation ça... par contre quel rapport avec sprintf() ?
Citer : Posté le 20/08/2018 08:37 | #
Aucune idée, mais mettre en static const int a enlevé l'erreur de eh_frame, et depuis que je l'ai fait le sprintf marche (j'ai rien changé d'autre, j'ai remis le makefile original).
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/08/2018 08:39 | #
Je vois. En théorie ça devrait marcher quand même donc je t'invite à réessayer le int une fois que tu te seras débarrassé de .eh_frame. En gros c'est une section qui contient des données qui permettent de remonter les appels de fonctions quand une exception se produit dans un programme C++. Tu peux carrément dire au compilateur de ne pas la générer en passant l'option -fno-asynchronous-unwind-tables.
Citer : Posté le 20/08/2018 08:43 | #
Ca marche pas, j'avais déjà essayé
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/08/2018 08:46 | #
Tu peux certainement faire mieux que « ça marche pas ». Qu'est-ce qui ne marche pas ?
Citer : Posté le 20/08/2018 08:49 | #
L'option n'a absolument aucun effet, l'erreur reste.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/08/2018 08:50 | #
La façon la plus safe reste d'éditer le linker script. Tu dois avoir quelque chose comme ça à la fin :
...
/DISCARD/ : {
*(.eh_frame)
}
}
Citer : Posté le 20/08/2018 08:58 | #
Il faudrait le rajouter dans le addin.ld du tuto du coup.
Ajouté le 20/08/2018 à 20:11 :
Du coup c'est chiant, je comprends même pas ce qui causait le bug : j'ai remis la déclaration en int, et j'ai enlevé le discard pour le eh_frame, et ça marche toujours... aucune idée de ce qui causait problème.
Est ce que ça pourrait être lié à la limite des 8 ko de ram statique ? Parce que dans ce cas je vais sûrement avoir beaucoup de bugs (sachant qu'avec Edit j'atteignais déjà la limite, alors avec micropython en plus on doit largement la dépasser)
Concernant le pow(), est ce que ça marche chez toi ? En rajoutant le volatile dans ton programme, j'ai toujours une system error.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/08/2018 20:43 | #
Malheureusement, comprendre les bugs ce n'est pas toujours facile. Je l'ai déjà mentionné il me semble, mais les bugs de gint me prennent parfois deux-trois jours à localiser, et pourtant je commence à avoir des réflexes.
Une possibilité, ce serait ça :
- Une déclaration en int envoie des choses dans la RAM (ça on sait)
- Pour une raison inconnue, cela incite le compilateur à générer des infos dans .eh_frame (hypothèse)
- La section .eh_frame n'était pas dans le linker script donc le linker la mettait où il pouvait (ça on sait)
- Elle finissait en collision avec la section C, celle du code de fxlib (ça on sait)
- Il est donc possible qu'elle se fasse charger sur sprintf(), écrasant une partie du code (hypothèse)
Non, le problème n'est clairement pas la RAM statique.
Je n'ai pas encore testé, je fais plein de trucs à la fois. Je me note d'y jeter un oeil.
Citer : Posté le 21/08/2018 01:13 | #
Concernant le g1a-wrapper, d'après mes tests il inverse la couleur des bmp monochromes (par contre les bmp 24 bits vont bien).
Ecrivez vos programmes basic sur PC avec BIDE