[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 03/12/2018 16:53 | #
En même temps, fxlib.h c'est absolument pas la même chose que stdlib.h.
Comme j'ai dit il faut que tu prennes les headers ici :
https://github.com/Zezombye/casiopy/tree/master/ports/minimal/include
D'ailleurs windows et GCC ne sont pas exclusifs : tu peux utiliser cygwin, ou même simplement le sh3eb-elf-gcc.exe avec la ligne de commande windows. (et j'ai un projet pour faire un SDK qui compile avec gcc)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 03/12/2018 16:58 | #
Comment ça, impossible ? C'est faisable, je le garantis.
La version actuelle de gint pèse 30 ko. C'est pas rien, mais un jeu moyennement bien codé sur le SDK fait facilement plus de 100 (au hasard, Jetpack Joyride dans lequel j'ai un peu mis les mains). Aussi, utiliser sprintf() coût 18 ko, donc normalement la taille n'est pas un facteur gênant...
Ajouté le 03/12/2018 à 16:59 :
Il s'agit vraiment d'ajuster ce que tu avais déjà compilé en recompilant une fraction des fichiers, vraiment rien d'aussi compliqué. (En plus c'est ton PC qui travaille.)
Citer : Posté le 03/12/2018 17:00 | #
Pour être franc avec toi j'ai d'abord utiliser tes headers, et j'ai eu le même problème. J'ai même converti l'addin avec l'outils SH3-SH4 (au cas où) mais ça n'a rien changé. Je sais pas si j'ai fait un truc à l'envers mais peu importe. Gint est tellement parfait il est juste si... lourd. Du coup pour les petits progs ça sera sur Windows, pour des plus grands projets ça sera sur Linux à voir. Mais toujours merci pour votre aide ce fut une expérience très formatrice.
EDIT: Pour Lephe, en effet tu marques des points pour les questions de taille mais pour des petits projets on peut facilement se passer de sprintf(), pour la question de l'addin qui tourne ou pas, quand je trafique pas les headers de Monochromelib tout va bien, ça compile ça tourne tranquillement pas de problème à ce niveau là.
Citer : Posté le 03/12/2018 17:04 | #
Mais tu as quel problème exactement ? Ca compile pas, ça crashe sur la calto ? x)
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 03/12/2018 17:05 | #
ça crash sur la calto
Citer : Posté le 03/12/2018 17:06 | #
Ta calto est en SH4 ? J'avais un crash avec ML en SH4 personnellement (je sais plus trop comment je l'ai résolu par contre).
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 03/12/2018 17:07 | #
Oui en SH4, pour info quand je suis sur Windows il n'y a pas de problème (en passant par l'outil SH3-SH4)
Citer : Posté le 03/12/2018 17:09 | #
As-tu essayé de compiler MonochromeLib avec l'option -O0 (c'est une lettre O suivi du chiffre zéro) ?
Citer : Posté le 03/12/2018 17:09 | #
Le même g1a qui fait crasher ta calto marche-t-il sur le sdk (qui est en SH3) ?
Si oui, c'est un problème de ML (et du coup mes headers marchent).
Pour le régler, j'avais fait la méthode "assembleur" :
- Commente la fonction ml_vram_adress dans monochromelib.c
- Crée un fichier syscalls.s que tu ajoutes à ton projet avec une syntaxe comme ceci : https://github.com/Zezombye/casiopy/blob/master/ports/minimal/syscalls.s
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 03/12/2018 17:17 | #
Ololo vous me donnez mal à la tête... pour le -O0 non j'ai pas tenté je sais pas ce que ça fait et non j'ai pas tenté le g1a sur l'émulateur... mais c'est mort j'ai abandonné je vais peut être revenir sur le sujet dans 1 an
Citer : Posté le 03/12/2018 19:34 | # |
Fichier joint
Salut ! J'ai essayé d'exécuter cette commande : sudo make all-target-libgcc mais elle me retourne une erreur(voir fichier joint).
Pouvez vous m'aiguiller ?
Citer : Posté le 03/12/2018 19:58 | #
Actuellement le makefile se plaint que les options du compilateur aient changé en plein milieu de son travail. Est-ce que tu as tout fait d'un coup, ou tu as fermé ton terminal à un moment ? Est-ce que as changé $PREFIX entre la compilation de GCC et de libgcc ?
Les dernières lignes te suggèrent de recommencer proprement : d'abord make distclean (cela nettoiera tous les fichiers que tu as compilés), puis de repartir au début de l'étape 5.
Avant de faire cela, si tu peux nous montrer les commandes que tu as tapées depuis que tu as compilé binutils, ça nous aiderait à trouver le problème (pour t'éviter de retomber dans le même souci).
Citer : Posté le 03/12/2018 20:10 | #
Merci pour ta réponse ! J'ai tout fait d'un coup et tout mis dans le .bashrc. Non, je n'ai pas changé le $PREFIX entre les deux compilations.
cd binutils-2.30
./configure --prefix=$PREFIX --target=$TARGET --disable-nls
make -j2
sudo make install
cd ../
cd gcc-7.3.0
./configure --prefix=$PREFIX --target=$TARGET --enable-languages=c,c++ --without-headers --with-newlib --disable-nls
make -j2 all-gcc
sudo make install-gcc
Ensuite c'est le beug
Citer : Posté le 03/12/2018 20:23 | #
Je suis sensiblement certain, au vu des logs, que $PREFIX est vide lorsque tu lances ta dernière commande. Est-ce que l'installation se passe correctement ? Tu peux essayer d'afficher la valeur (echo $PREFIX) avant de lancer la compilation de libgcc pour vérifier qu'elle est correcte.
Citer : Posté le 03/12/2018 20:38 | #
l'installation se passe correctement, aucune erreur. Et tu as raison $PREFIX est vide.
Citer : Posté le 03/12/2018 20:42 | #
Dans ce cas, soit tu peux chercher pourquoi $PREFIX est devenue vide sans trop de raison apparente, soit tu refais un coup de export PREFIX=... et tu continues le tutoriel. :3
Citer : Posté le 03/12/2018 20:43 | #
D'accord, merci ! Je vais essayer de faire ça
Citer : Posté le 14/12/2018 19:28 | #
Salut, j'essaye de manipuler les fichiers avec les fonctions Bfile_OpenFile() etc... Or à la compilation j'obtiens cette erreur :
C:\Documents and Settings\���c���i\My Documents\fx-9860G SDK files\filebios.c:(P+0x6c0): undefined reference to `_strncmp'
Donc j'imagine que c'est une simple erreur de portage... Aurais-tu une piste pour résoudre le problème ? J'ai songé à changer le chemin mais je ne sais pas où se trouverait l'équivalent de "filebios.c"
EDIT : Ah quel hasard je viens de prendre connaissance de la biblio "memory", il me semble que j'ai vu des fichiers memory.h trainer quand je cherchais sur mon Linux je vais voir ça
EDIT : Bon j'ai regardé le code source de memory.c, et cela utilise les fonctions de Bfile... du coup retour à la case départ
Citer : Posté le 14/12/2018 20:35 | #
Tiens c'est assez lol tout ça. En gros Bfile_DeleteFile() utilise la fonction strncmp() mais le linker te dit qu'il ne la trouve pas, alors qu'elle devrait être dans libfx.a, justement. Est-ce que ton fichier libfx.a est d'origine ? Je veux bien en avoir une copie.
Dans le pire des cas tu peux toujours réimplémenter strncmp(), mais c'est un peu bourrin... as-tu d'autres erreurs de ce type (undefined reference to) ?
Citer : Posté le 14/12/2018 22:13 | #
Je mets mon libfx.a même si théoriquement il est de cette page. Ce qui me dérange le plus dans cette histoire c'est le chemin absolu qui est propre à Windows alors que je suis bien sur Linux. Le coupable est le fichier "filebios.robj" il y a marqué dedans le chemin (j'ai regardé avec Ghex).
Citer : Posté le 14/12/2018 22:14 | # |
Fichier joint
Désolé pour le retard, j'ai mis à upload le fichier puis 1h plus tard j'ai remarqué que l'extension n'était pas acceptée. Le voici ci-joint.