[Tutoriel] Compiler sous Linux avec un cross-compilateur gcc
Posté le 31/05/2014 17:02
Qui dit Linux implique son puissant compilateur gcc, et de nombreux outils permettant de développer plus librement, plus efficacement. Dans ce tutoriel, je vous propose de compiler GCC et sa suite pour développer des programmes pour les calculatrices Casio.
Pour pouvoir bien suivre, vous devez savoir vous servir d'un terminal et des commandes de base. Ouvrez-en un pour commencer, et essayez de ne pas le fermer par erreur, ça pourrait gêner. Accrochez-vous bien !
Sommaire
1.
Installation des dépendances
2.
Considérations sur l'architecture cible
3.
Préparation de l'environnement de compilation
4.
Compilation de binutils
5.
Compilation de gcc et de libgcc
6.
Compilation de newlib (experts)
7.
Choisir un environnement de développement
1. Installation des dépendances
Dans ce tutoriel, on va compiler plusieurs programmes : d'abord
binutils, une suite d'outils qui gère les programmes en assembleur, l'édition des liens, les fichiers exécutables et tout ce qui n'est pas du C ; ensuite le compilateur
gcc qui compile le code C en assembleur ; et si vous êtes aventureux, peut-être même une version expérimentale de
newlib, une bibliothèque standard qui fournit les fonctions fondamentales du C.
Le
gcc qui compile vers la calculatrice produit du code en assembleur SuperH, ce n'est
pas celui de votre système qui compile probablement en assembleur x86_64. Il ne s'appelle
pas gcc mais quelque chose de plus long comme
sh-elf-gcc. Vous devez faire très attention à ne pas confondre les deux !
À l'heure où j'écris cette version du tutoriel (12 Septembre 2019), les dernières versions disponibles sont
binutils-2.32 et
gcc-9.2.0. N'hésitez pas à prendre des versions plus récentes, tant que vous les prenez proches dans le temps. Attention, la dernière version n'est pas toujours en bas de la liste ! La communauté d'OSDev (qui compile
gcc à tour de bras) a un tableau où elle indique les combinaisons qui ont marché. Si vous en réusissez une nouvelle, allez leur dire.
La manipulation peut échouer à cause d'erreurs de compilation imprévisibles et que vous ne saurez souvent pas résoudre ; en général soit il vous manque des dépendances soit vous êtes tombé sur des versions qui ne veulent pas marcher chez vous, vous pouvez alors essayer avec d'autres.
Téléchargement de binutils
Téléchargement de gcc
Compilations réussies par la communauté d'OSDev
Bien sûr
gcc est un logiciel complexe qui s'appuie sur différentes bibliothèques pour faire son boulot : il y a donc un certain nombre de dépendances à installer. Les noms de paquets ci-dessous sont pour Debian et ses dérivés (Ubuntu, Mint, ElementaryOS...), à utiliser avec
apt. Si vous avez une autre distribution vous saurez vous débrouiller.
mpfr (libmpfr-dev) : flottants à précision variable
mpc (libmpc-dev) : complexes à précision variable
gmp (libgmp-dev) : arithmétique à multi-précision
png (libpng-dev) : manipulation d'images
ppl (libppl-dev) : polyèdres Parma (optimisation magique)
flex (flex) : générateur d'analyseurs lexicaux
g++ (g++) : compilateur C++
git (git) : gestionnaire de versions
2. Considérations sur l'architecture cible
Les processeurs des calculatrices Casio font partie de la lignée des SuperH, et vous savez peut-être qu'il y en a deux versions en circulation : les vieilles machines d'avant 2012 utilisent des processeurs SuperH-3, et les autres des SuperH-4A. Un certain nombre de membres anciens et respectés utilisent toujours des SH3, donc il est important de pouvoir créer des programmes pour les deux.
Dans ce tutoriel, on va compiler un GCC qu'on appellera
sh-elf-gcc qui sera capable de cibler deux architectures : SuperH-3 et SuperH-4 sans FPU.
La méthode proposée dans les anciennes versions du tutoriel ne permettait que de cibler une seule architecture à la fois. Les compilateurs s'appelaient alors
sh3eb-elf-gcc et
sh4eb-nofpu-elf-gcc. Vous pouvez toujours utiliser le premier, mais cela n'a plus vraiment d'intérêt puis qu'on peut avoir les deux ensemble. Le deuxième n'est pas
véritablement sans FPU et pose des problèmes sérieux : ne l'utilisez pas.
Passons aux choses sérieuses maintenant !
3. Préparation de l'environnement de compilation
Tout ce qu'on va créer aujourd'hui ira dans un dossier de votre ordinateur. Le compilateur sera installé là, et les bibliothèques pour programmer sur la calculatrice seront là aussi. Je vous conseille vivement de choisir un dossier dans votre répertoire personnel. Pour moi, ce sera dans
$HOME/opt avec le numéro de version car j'en compile souvent. Vous pouvez choisir ce que vous voulez, par exemple
$HOME/Documents/Casio/gcc (ça ne changera rien à la suite).
% export PREFIX="$HOME/opt/sh-elf-2.32-9.2.0"
% mkdir -p $PREFIX
% cd $PREFIX
Si vous fermez votre terminal au milieu du tutoriel, et en ouvrez un autre ensuite, retapez ces trois commandes, retapez le
export PATH plus bas, puis reprenez le tutoriel là où vous étiez arrêté.
Extrayez le contenu des archives que vous avez téléchargées dans ce dossier, et créez deux répertoires
build-binutils et
build-gcc. Si par exemple les archives sont au format
.tar.xz dans le dossier que vous venez de choisir, vous pouvez les extraire avec
tar. Pour créer les sous-dossiers, utilisez
mkdir comme d'habitude.
% tar -xJf binutils-2.31.1.tar.xz
% tar -xJf gcc-8.2.0.tar.xz
% mkdir build-binutils build-gcc
Après cela, votre dossier doit ressembler ceci quand vous exécutez la commande "
tree -L 1" :
% tree -L 1
.
├── binutils-2.32
├── binutils-2.32.tar.xz
├── build-binutils
├── build-gcc
├── gcc-9.2.0
└── gcc-9.2.0.tar.xz
Le compilateur et tous les outils de sa suite vont arriver dans un sous-dossier
bin. Pour pouvoir les utiliser sur la ligne de commande, vous devez les ajouter au
PATH. (Le
PATH est l'ensemble des dossiers dans lesquels le terminal cherche les commandes.) Utilisez la commande ci-dessous pour modifier temporairement le
PATH.
% export PATH="$PATH:$PREFIX/bin"
La modification sera perdue quand le terminal sera fermé. Pour que ce changement soit permanent, il faut ajouter la commande à la fin du fichier
$HOME/.profile. La commande suivante le fait pour vous.
% echo "export PATH=\$PATH:$PREFIX/bin" >> $HOME/.profile
4. Compilation de binutils
La compilation de
binutils est très classique : d'abord on configure nos options avec
./configure, ensuite on compile avec
make, puis on installe avec
make install. C'est comme ça pour un nombre incalculable de logiciels.
Notez (ça marche jusqu'à la fin du tutoriel) que
make possède une option
-j pour compiler avec plusieurs processus en même temps, pour aller plus vite. Utilisez toujours
-j suivi d'un nombre, typiquement votre nombre de coeurs. Pour moi,
-j4.
Choisir le bon nombre de threads pour -j (pour ceux que ça intéresse)
% cd build-binutils
% ../binutils-2.32/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --disable-nls --program-prefix=sh-elf-
Ici, l'option
--prefix indique où on va installer le compilateur.
--target avec
--with-multilib-list permet de spécifier à la fois SuperH-3 et SuperH-4 sans FPU comme cibles. Enfin,
--program-prefix permet de donner un nom personnalisé au compilateur, ici
sh-elf-gcc.
(experts) La liste complète des options de compilation est donnée par
configure --help, en voici quelques-unes suscesptibles de vous intéresser :
--disable-nls pour forcer les diagnostics en anglais
--disable-werror pour supprimer l'option
-Werror
--enable-libssp pour compiler
libssp (protection de pile)
--enable-lto pour activer le support des optimisations au linkage (puissant)
Une fois que tout est configuré, il n'y a plus qu'à compiler et à installer. Normalement ça va assez vite, comptez quelques minutes. Si vous avez une erreur de compilation, vérifiez les dépendances et les en-têtes possiblement manquants. Sinon, changez de version de
binutils et éventuellement de
gcc.
% make -j4
% make install
Les exécutables de
binutils ont dû apparaître dans
$PREFIX/bin. Essayez de taper
$PREFIX/bin/sh-elf-as --version pour vérifier que ça marche !
5. Compilation de gcc et de libgcc
Maintenant, on recommence pareil, mais cette fois on compile un morceau beaucoup plus gros :
gcc. L'option
--enable-languages vous permet de choisir les langages que vous voulez pouvoir compiler, notamment C, C++, Ada, Go ou Fortran. Attention au temps de compilation qui va vite monter !
% cd $PREFIX/build-gcc
% ../gcc-9.2.0/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --enable-languages=c,c++ --without-headers --with-newlib --disable-nls --program-prefix=sh-elf-
(experts) Les options
--disable-werror,
--enable-libssp et
--enable-lto doivent être passées ici aussi si vous les avez passées à
binutils.
Et c'est parti pour compiler ! Comptez entre 10 et 30 minutes (pour
c,c++) selon la puissance de votre ordinateur, 5 à 6 heures sur un vieux Raspberry Pi !
% make -j4 all-gcc
% make install-gcc
GCC fournit également une bibliothèque appelée
libgcc qui contient des fonctions indispensables. Tout le code compilé avec
gcc doit être linké avec
libgcc. On compile donc cette bibliothèque, ce qui se passe très vite et sans la moindre difficulté.
% make -j4 all-target-libgcc
% make install-target-libgcc
Vous pouvez désormais taper
sh-elf-gcc -m3 et
sh-elf-gcc -m4-nofpu et vous devez avoir juste une erreur fatale indiquant que vous n'avez pas donné de fichier à compiler. Si on prend une autre cible, par exemple avec
sh-elf-gcc -m4, GCC doit se plaindre que
-m4 n'est pas supporté parce que ne l'a pas demandé.
Si tout s'est bien passé, alors vous avez terminé ce tutoriel ! La partie 7 vous guidera vers un SDK pour créer vos add-ins
6. Compilation de newlib (experts)
Memallox a construit un
port de newlib (en anglais) pour supporter une libc avec
gcc. Pour l'instant c'est au stade expérimental ; vous pouvez sauter cette section jusqu'à ce que ce soit bien étudié. Si vous savez de quoi vous parlez, vous pouvez le compiler maintenant.
Clônez le
dépôt de Memallox dans le répertoire de travail ou créez un lien symbolique. Ensuite, configurez de la même façon :
% git clone https://git.planet-casio.com/Memallox/libc
% mkdir build-newlib
% cd build-newlib
% ../libc/configure --prefix=$PREFIX --target=sh3eb-elf --enable-target-optspace
% make -j4
% make install
Là aussi les options de configuration
--enable-libssp et
--enable-lto peuvent vous intéresser. Ensuite, recompilez
gcc (avec les mêmes options, en particulier
--without-headers et
--with-newlib) :
% cd build-gcc
% ../gcc-9.2.0/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --enable-languages=c,c++ --without-headers --with-newlib --disable-nls --program-prefix=sh-elf-
% make -j4 all-gcc
% make install-gcc
% make -j4 all-target-libgcc
% make install-target-libgcc
Je ne suis pas sûr qu'il soit nécessaire de recompiler
libgcc mais ça ne coûte rien !
7. Choisir un environnement de développement
Maintenant que vous avez le compilateur, vous pouvez écrire des add-ins ! Enfin... presque. Il vous manque encore de quoi écrire à l'écran, récupérer les touches pressées sur le clavier, et convertir vos images.
Pour ça, vous avez (à l'heure où j'écris cette version du tutoriel), deux choix : utiliser fxlib porté pour GCC, ou bien utiliser
le fxSDK.
Jusqu'ici le tutoriel pour développer des add-ins avec fxlib était sur cette page, mais je vais le déplacer dans un topic à part. Je l'ai temporairement laissé dans le spoiler ci-dessous.
Pour le fxSDK, la page du projet détaille son installation et son utilisation. C'est plus facile que GCC donc vous avez déjà quasiment tout fait !
Ancien tutoriel d'utilisation de fxlib (commence à être très vieux)
Cliquez pour recouvrir
Installation du g1a-wrapper
Votre
binutils produit des fichiers au format ELF. Il y a encore un peu de travail à faire avant d'obtenir un
g1a. Le
g1a-wrapper est un petit programme qui va nous y aider. Clônez-le depuis un dépôt git et installez-le dans le dossier des binaires du compilateur.
% cd $PREFIX
% git clone "https://Lephenixnoir""@""bitbucket.org/Lephenixnoir/add-in-wrapper.git"
% cd add-in-wrapper
% make
% cp build/g1a-wrapper $PREFIX/bin
Environnement de projet
On va créer un modèle de projet que vous pourrez réutiliser. Tout ça se passe en-dehors de la compilation de gcc, je vous conseille donc de changer de dossier.
~/my-awesome-project pourrait être sympa. Dans tous les cas, vous pouvez fermer le terminal pour l'instant. Si vous avez de l'expérience dans la programmation C, je ne vais pas vous apprendre à organiser un projet... il vous faudra juste quelques fichiers donnés plus bas.
Voilà par exemple comment on pourrait organiser un projet:
- un dossier
include contenant les 6 headers de fxlib (
dispbios.h,
endian.h,
filebios.h,
fxlib.h,
keybios.h,
timer.h)
- la bibliothèque
libfx.a
- les fichiers
addin.ld et
crt0.s
- une icône, par exemple
icon.bmp
- les sources (dans un dossier
src par exemple)
Le code de base est un peu plus simple qu'avec le SDK (toutes les choses bourrines ayant été mises dans
crt0.s) :[/justify]
#include <fxlib.h>
int main(void)
{
unsigned int key;
locate(1, 1);
Print((unsigned char *)"gcc add-in");
while(1) GetKey(&key);
return 1;
}
Tous ces fichiers sont prêts à utiliser dans l'archive suivante.
Télécharger le projet d'exemple
Voilà sans plus attendre la commande à utiliser pour compiler ce nouveau projet. Y'a plein d'options, mais rien de bien méchant, vous allez voir...
$ sh3eb-elf-gcc -m3 -mb -mrenesas -ffreestanding -nostdlib -T addin.ld crt0.s addin.c -o addin.elf -I include -lgcc -L . -lfx -O2
- Les options -m3 et -mb indiquent qu'on veut du code pour SH3 (même si on utilise déjà le sh3eb-elf, il y a plusieurs variantes) utilisant le big-endian (cela concerne l'ordre des octets en mémoire dans des variables de plusieurs octets)
- L'option -mrenesas demande à GCC de produire du code compatible avec fxlib
- L'option -ffreestanding signale que le programme compilé tient « tout seul », sans s'appuyer sur un système d'exploitation (gcc fournit alors deux-trois choses en plus)
- L'option -I include indique que certains de nos fichiers d'en-tête sont dans le dossier include
- L'option -nostdlib indique que l'on n'a pas de bibliothèque standard (elle est dans fxlib)
- L'option -O2 active l'optimisation du code (facultatif, mais utile)
Ça c'est les options de compilation proprement dites. Ici, on compile tout d'un coup et on effectue l'édition des liens (génération du fichier exécutable) dans la foulée, donc les options se mélangent. Si vous avez un gros projet, vous allez compiler les fichiers un par un avec -c et tout linker ensuite. Les options que j'ai citées pour l'instant sont celles qu'on utilisera à la compilation. Les options suivantes sont spécifiques au linkage :
- L'option -T addin.ld indique au compilateur que les règles qu'on l'on veut voir respecter lors de l'édition des liens sont dans le fichier addin.ld
- Les options -L . et -lfx indiquent qu'on veut utiliser fxlib, et que le fichier libfx.a se trouve dans le dossier courant
- L'option -lgcc spécifie l'utilisation de libgcc (il faut toujours utiliser libgcc !)
- Bien sûr, -o addin.elf indique le nom du fichier de sortie
Notez que le fichier crt0.s est un autre fichier source qui contient du code indispensable. Pensez à le compiler aussi, ici en même temps que le programme addin.c. Le fichier de sortie est au format ELF (le format classique sous Linux), ce qu'on avait prévu en compilant un gcc pour l'architecture sh3eb-elf.
Génération du g1a
Le format ELF a plein d'avantages, mais on ne veut que du binaire pur. Pour cela, on va utiliser un programme de binutils, objcopy, qui va nous permettre de changer le format. En deux mots, supprimer l'ELF et ne garder que le binaire pur (ce qui est dit par -O binary). On supprime aussi deux-trois sections au passage (.comment et .bss), n'oubliez pas de le faire sinon vous aurez un fichier énormissime en sortie.
$ sh3eb-elf-objcopy -R .comment -R .bss -O binary addin.elf addin.bin
On n'a plus maintenant qu'à ajouter les informations de l'application add-in pour obtenir un fichier g1a. C'est le boulot du g1a-wrapper. Il y a des options pour pas mal de champs (que vous pouvez obtenir en exécutant g1a-wrapper --help), mais faisons simple et mettons juste une icône :
$ g1a-wrapper addin.bin -o addin.g1a -i icon.bmp
Terminé ! Vous n'avez plus qu'à transférer votre nouvel add-in... pour ça, seul un bon vieux terminal et des programmes en ligne de commande sont désormais dignes de vous. On en a quelques-uns :
- Le grand
P7 de Cakeisalie5
-
CasioUsb de Nessotrin
Merci d'avoir suivi ce tuto ! N'hésitez pas à laisser vos impressions, idées d'amélioration, messages de réussite ou même messages d'erreur dans les commentaires !
Fichier joint
Citer : Posté le 08/06/2014 13:37 | #
Compiler sur Android ? À moins que l'on puisse compiler gcc sur Android, je ne vois pas trop comment...
Ajouté le 08/06/2014 à 14:01 :
Tutoriel terminé !
Citer : Posté le 08/06/2014 14:08 | #
Avec l'application CCTools, il y a un add-on GCC, qui permet de justement de compiler du C, donc je me demande si il y aurait un moyen
Citer : Posté le 08/06/2014 14:19 | #
Oui, mais ça doit être un gcc compilé pour Android ?
Citer : Posté le 08/06/2014 14:30 | #
Oui surement
Citer : Posté le 08/06/2014 14:33 | #
Ah... peut-être.
Peut-être que tu pourrais compiler un gcc pour la calto en utilisant le gcc présent sur l'Android. Mais il faut aussi le make...
Citer : Posté le 08/06/2014 15:42 | #
Mais je me pose des questions sur la compatibilité sh4... Est-ce qu'on aura encore besoin du code de compatibilité ou d'une toolchain sh4eb-elf ?
Coïncidence ? Je ne pense pas.
Citer : Posté le 08/06/2014 15:50 | #
Il faut faire la différence entre la question de la spécificité de la machine et de l'architecture SH4. Au niveau de l'architecture il ne devrait pas y avoir de soucis : on compile avec cette toolchain pour la Prizm, qui a un SH4.
C'est au niveau de la machine que se trouve le "problème" : changement d'adresse de certains registres/mémoires par exemple, et ça, GCC n'en a que faire car c'est "nous" (ou la lib de casio) qui utilisont ces adresses, lui compile simplement du code compréhensible par tout les processeurs SH3 en fonction de ce qu'on lui donne. D'ailleurs on remarquera qu'un code compilé avec le sdk de Casio (à la base pour sh3 donc) est parfaitement exécutable en tant que suite d'instruction sur une calculette SH4 (ensuite si ces instructions "essayent" de lire dans un registre processeur / une mémoire qui n'existe plus, c'est un autre problème).
Compiler avec une toolchain SH4 ne résoudra pas le problème (du moins je pense bien). C'est donc dans du "code de compatibilité" qu'il va falloir "taper".
Citer : Posté le 10/06/2014 10:20 | #
Je viens de finaliser le tuto. Quelques fautes d'orthographe, grammaire et syntaxe corrigées et un sommaire ajouté.
Le tout en 10 étapes.
Citer : Posté le 10/06/2014 10:47 | # |
Fichier joint
Si tu veux Eiyeron, je regarderai ce soir si il y a moyen de récupérer les binaires du PrizmSDK (Je pense que oui perso) ;).
Et pour Florian66, le cross compilateur te permet de compiler des programmes destinés à être exécutés sur une certaine architecture (ici SuperH) à partir d'une machine basée sur un autre architecture (ton PC en l'occurrence, donc du x86 je suppose). En gros c'est : faire des addins sans utiliser le SDK de Casio.
Bump, alors, ça avance l'idée? Je suis pas très chaud, j'ai l'impression que l'on compile d'une arch pour une autre arch. Si tu veux j'ai déjà bricolé des ficheirs de règles à partir du PrizmSDK.
Citer : Posté le 14/06/2014 11:18 | #
Lephénix, tu avais fait un makefile non ? Tu pourrais le partager que je vois à quoi il ressemble (je suis un néophyte en matière de makefile) ?
Páranÿe quetë Quendya
Citer : Posté le 14/06/2014 11:32 | #
Je l'ajouterai au tuto plus tard.
Citer : Posté le 14/06/2014 22:30 | # |
Fichier joint
Bref, voici une archive zip contenant un projet "par défaut" :
Tout les fichiers sont dedans :
Dans "bin" :
-> addin.ld
-> ctr0.s
-> g1a_header.h
-> g1awrapper (attention à remplacer le g1awrapper par le votre, celui donné ici peut être incompatible avec votre distribution)
Dans "include" :
-> Les header de fxlib
A la racine :
-> fxlib.a (la librairie fxlib compatible GCC)
-> icon.bmp (l'icone de votre programme)
-> main.c (le fichier "par défaut")
-> addin.g1a (l'exemple de l'addin par défaut)
-> Makefile (un makefile fait par LePhenixNoir et moi-même)
Utilisation du makefile :
Placez vous à la racine du projet dans le terminal puis :
Modifiez la ligne "NAME = addin" par le nom de l'addin à créer. De même, modifiez les premières lignes pour choisir votre compilo et g1awrapper.
La ligne "SRC = $(wildcard *.c)" correspond aux fichiers qui seront compilés. Par défaut tous le sont. Pour faire une liste précise, remplacez par "SRC = main.c fichier1.c fichier2.c)". Le reste se fait automatiquement.
Une fois que ce fichier a été configuré, quittez Nano en enregistrant, puis vous pouvez utiliser :
Páranÿe quetë Quendya
Citer : Posté le 15/06/2014 10:58 | #
Génial, merci.
Je commence à penser qu'il faudra vraiment qu'on fasse un fxSDK pour Linux, ça serait tellement plus pratique...
Quoique la ligne de commande, j'aime bien aussi
Citer : Posté le 27/06/2014 14:04 | #
J'ai fait un peu de recherche sur les options de GCC et j'ai trouvé cette page qui les recense.
Il y en a quelques-unes qui pourraient nous être utiles notamment
--with-endian=big [green]//pour ne pas taper -mb à chaque fois[/green]
Ainsi que toutes les options listées dans "Cross-Compiler-Specific Options"
Dont, par exemple
--with-libs="dir1 dir2 ... dirN"
Ou carrément
Je regarde ça et je vous tiens au courant !
Coïncidence ? Je ne pense pas.
Citer : Posté le 27/06/2014 14:04 | #
C'est à la compilation de gcc ces options ?
Citer : Posté le 27/06/2014 14:05 | #
Oui
Coïncidence ? Je ne pense pas.
Citer : Posté le 27/06/2014 14:06 | #
Le problème, c'est que du coup ces options sont permanentes...
Citer : Posté le 27/06/2014 14:07 | #
je ne pense pas : on peut toujours spécifier -nostdlib à la compil par exemple
Coïncidence ? Je ne pense pas.
Citer : Posté le 27/06/2014 14:09 | #
Oui mais on ne pourra pas annuler les options ajoutées à la compilation, c'est un peu le problème... si on venait à utiliser un compilateur SH4, on ne pourrait pas sans recompiler gcc.
De plus, comme on utilise un Makefile... mais bon, ça peut rester utile quand même.
Citer : Posté le 27/06/2014 14:12 | #
Ben recompiler gcc, c'est pas la mer à boire, j'ai déjà deux cross-gcc... (une sh3-elf et une sh4-elf)
enfin pas pour tout le monde...
(j'aurais mieux fait de me taire...)
Coïncidence ? Je ne pense pas.
Citer : Posté le 27/06/2014 14:13 | #
Oui, c'est vrai que DS a eu du mal
Non mais c'est pratique.