[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 04/01/2015 19:05 | #
sh3eb-elf-ar -q libbiblio.a objet.o
Citer : Posté le 04/01/2015 19:12 | #
Tu n'as pas besoin du linker script pour pour compiler la bibliothèque : tu peux retirer -T"../common/addin.ld" (à mon avis, si je dis une bétise arrêtez moi
De plus, un des intérêts à faire une bibliothèque (pour MonochromeLib par exemple) serait de séparer chaque fonction dans un fichier objet différent, comme ça pas besoin de s'embêter avec les defines pour avoir un exécutable final le plus léger possible.
Citer : Posté le 04/01/2015 21:32 | #
sh3eb-elf-ar -q libbiblio.a objet.o
Pas de linkage pour la compilation d'une bilbiothèque !
Donc option -C, je l'ai écrit et tu l'as cité ! >_<
Pas de linkage donc pas d'options associées : tu peux virer le -nostdlib, le linker script, le -lgcc, le -L ../lib et le -lfx, bref tu n'as besoin que de :
sh3eb-elf-ar mcv libfichier.a fichier.o
Citer : Posté le 05/01/2015 13:35 | #
ça me met une erreur
Citer : Posté le 05/01/2015 17:49 | #
Peut-être qu'en rajoutant -nostdlib ?
Coïncidence ? Je ne pense pas.
Citer : Posté le 05/01/2015 21:16 | #
Arf, erreur de ma part, c'est un c minuscule.
Toutes mes excuses.
Citer : Posté le 29/03/2015 15:28 | #
Tiens au fait, je linke vers ma traduction
If someone's looking for it, here's the english translation : http://www.planet-casio.com/Uk/forums/topic59-1-%5Btutorial%5D-Build-addins-on-linux-using-a-cross-gcc-toolchain.html
et si un admin pouvait rajouter certains / dont on dirait qu'ils ont disparu, ce serait sympa !
Coïncidence ? Je ne pense pas.
Citer : Posté le 19/04/2016 12:20 | #
J'ai complètement revu le tuto. En particulier j'ai bien réduit la fin qui comportait pas mal de trucs inutiles. ^^'
Je suis passé sur mon wrapper, ce sera plus facile s'il y a des problèmes.
Quand on aura le fxSDK ce sera (encore) plus simple.
Citer : Posté le 22/08/2016 19:22 | #
Hé, je me ramène avec ma publicité mais comme il faut savoir se vendre, c'est possible de citer P7 à la fin stp ? Merci d'avance
Mon blog ⋅ Mes autres projets
Citer : Posté le 22/08/2016 20:03 | #
Bien sûr !
Ajouté le 11/09/2016 à 10:47 :
J'ai mis à jour le tuto (gcc 6.1.0 avec binutils 2.26). Modifié la rédaction, amélioré un peu tout, expliqué des trucs... les gens que s'y connaissent bien savent déjà tout ça mais je pense pas que ce soit la majorité du peuple.
Voilà voilà, c'était l'update régulière...
Citer : Posté le 05/02/2017 18:05 | #
Si vous n'arrivez pas à compiler, le flag -ffreestanding peut être nécessaire.
Citer : Posté le 05/02/2017 18:15 | #
Hmm, en fait le flag -ffreestanding est totalement nécessaire. J'ai modifié le tuto pour ajouter ça ; merci de l'avoir signalé.
Citer : Posté le 06/02/2017 14:07 | #
J'avais oublié de supprimer la section .bss l'autre fois, et je me suis retrouvé avec un fichier de plusieurs dizaine de Mo.
Pourquoi ? En m'informant un peu sur Wikipedia, cette section n'est censé contenir que les valeurs des variables non initialisés (et donc à 0). Pourquoi une section qui semble ne devoir prendre que quelques octets prend en fait autant de place ?
Citer : Posté le 06/02/2017 16:16 | #
J'imagine que c'est à cause du linker. Il ne se contente pas de mettre les sections les unes après les autres pour former me fichier exécutable, il les place dans la mémoire selon les indications du linker script qu'on lui fournit. Si on oublie des indications on peut même se retrouver avec des fichiers de plusieurs Go.
Sans voir ton exécutable ni le linker script directement je ne peux gager de rien, mais j'imagine que le linker a mis du padding entre les sections.
Citer : Posté le 27/04/2017 11:51 | #
Comme c'est plus marrant quand on peut faire plus de trucs, je teste les ajouts suivants au configure script :
Tout ça marche, je bloque simplement au niveau de la détection au compile-time du DSP (pour savoir si on va produire des instructions valides pour as, ou non).
Mon blog ⋅ Mes autres projets
Citer : Posté le 27/04/2017 12:59 | #
Activer l'endianness est inutile pour nous. Quant au fixed-point, je soupçonne qu'il utilise le DSP, et on n'en a pas... donc pas besoin de le détecter au runtime.
Pour le --with-cpu, j'aimerais bien savoir ce que c'est.
Citer : Posté le 27/04/2017 13:00 | #
Beh en gros, --with-cpu c'est le CPU par défaut, et --with-multilib-list c'est tous les CPUs que je veux que GCC gère. Donc je peux faire sh3eb-elf-gcc -m4al par exemple.
Mon blog ⋅ Mes autres projets
Citer : Posté le 27/04/2017 18:43 | #
Ah, pas mal. Peut-être que quand les SH3 auront totalement disparu de la circulation, on pourra se passer de la compatibilité et compiler directement pour SH4...
Citer : Posté le 15/05/2017 08:14 | #
J'ai vu que du côté de la libfxcg ils utilisaient l'option -mhitachi (à la compilation). Je sais que ça définit la constante __HITACHI__, mais j'ignore encore si ça "fixe" le comportement des variable argument lists, ce qui pourrait du coup faire marcher le sprintf de la libfx. J'ai essayé de tester, sans succès pour le moment. Si quelqu'un d'autre veut tenter, qu'il n'hésite pas.
Mon blog ⋅ Mes autres projets
Citer : Posté le 04/08/2017 16:13 | # |
Fichier joint
Je fais face à un problème, je sais pas trop où le mettre alors je le met ici.
Quand je cherche a compiler mon code, j'ai cette erreur qui apparrait:
src/mobile.cpp: In member function 'bool Mobile::colliObject(Object*, float)':
src/mobile.cpp:91:31: error: 'sqrt' was not declared in this scope
float dir_x = -dist_y/sqrt(r);
Je comprend pas trop pourquoi ça marche pas, est-ce qu'il y a un lien avec ce post ? ici
Les fichiers sont en annexe.
Merci d'avance
Citer : Posté le 04/08/2017 18:42 | #
À première vue, t'as pas inclus math.h dans tes headers. Par contre je sais pas si elle est définie dans le fxsdk.