[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 14/02/2021 14:00 | #
En principe oui. Comme c'est un outil un peu récent j'ai pas eu beaucoup de retours encore, donc tu pourrais croiser un bug ; mais on devrait s'en sortir.
Citer : Posté le 14/02/2021 15:03 | #
C'est bon j'ai installer Giteapc sous ubuntu wsl est ça marche merci beaucoup je vais pouvoir recompiler gravity duck pour Graph 35+e2!
Citer : Posté le 04/04/2021 19:10 | #
Salut Lephé !
Dans le tuto
Enfin, --program-prefix permet de donner un nom personnalisé au compilateur, ici sh-elf-gcc.
Citer : Posté le 04/04/2021 19:25 | #
Oui, c'est normal : le préfixe est ajouté à tous les noms d'outils (et il y en a beaucoup !). Par exemple quand tu compiles gcc, tu obtiens normalement gcc et g++, et ces deux auront le sh-elf- ajouté devant (note le tiret final, qui est important sinon tu te retrouves avec sh-elfgcc).
Citer : Posté le 04/04/2021 19:35 | #
Ok merci
Ajouté le 04/04/2021 à 20:40 :
Re : J'ai un message d'erreur à la compilation de gcc :
Un indice ?
PS : je suis sur macOS, la compilation de binutils c'est déroulée sans peine
Quelqu'un a déjà tout compilé sur mac ?
Citer : Posté le 04/04/2021 20:44 | #
Ton configure a dû échouer quelque part, c'est « trop gros » comme erreur.
Citer : Posté le 04/04/2021 20:51 | #
Hmm, en remontant le fil j'ai ça :
configure: error: Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+
J'ai bien installé gmp mpfr et mpc. Sauf que MPC est en 0.33 mais pourtant "up to date"
Il y a un sacré écart de version là entre 0.33 et 0.8 !
Citer : Posté le 04/04/2021 21:18 | #
Le mpc que tu as installé est un outil en ligne de commande pour contrôler MPD, un lecteur de musique. Le bon paquet s'appelle probablement libmpc ou un truc du genre (Multi-Precision Complex)
Citer : Posté le 04/04/2021 22:00 | #
C'était bien ça ! Merci
Citer : Posté le 01/05/2021 16:21 | #
Bonjour !
Quand j'ai une erreur avec gcc c'est sous la forme
/Users/olivier/Documents/CASIO/gcc/bin/../lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: CMakeFiles/Windmill.dir/src/windmill.cpp.obj: in function __ZN8Windmill8load_mapEP3Map':
windmill.cpp:(.text+0xe10): undefined reference to __ZdaPv'
J'aimerai pouvoir changer les points suivants :
- le chemin qui est hyper long, pouvoir le supprimer ou raccourcir
- le nom des fonction est pas trop lisible __ZN8Windmill8load_mapEP3Map
- la ligne est pas en décimal .text+0xe10
- pareil pour le nom de la fonction __ZdaPv
Il y a moyen de rendre plus lisible les messages d'erreur de gcc ?
Citer : Posté le 01/05/2021 16:25 | #
Donc ça ce n'est pas une erreur de g++, c'est une erreur de ld, l'éditeur de liens. La différence ? ld ne connaît pas le langage et il n'a pas le code source, pas de notion de fonctions, de lignes, etc.
• Raccourcir le chemin : pas possible à vue de nez.
• Pour le nom des fonctions, utilise c++filt :
Windmill::load_map(Map*)
% echo __ZdaPv | c++filt -_
operator delete[](void*)
• .text+0xe10 ce n'est pas un numéro de ligne c'est une position dans le code objet, tu ne peux rien y faire
L'absence de l'opérateur delete fait qu'il faut que tu l'implémentes, à ma connaissance tu peux juste faire free(), le compilateur se charge d'appeler le destructeur. À vérifier de préférence.
Citer : Posté le 01/05/2021 16:40 | #
Ok, merci de la réponse, est-ce possible d'utiliser c++filt en automatique ?
D'accord, il n'y a pas delete. ici dans mon code j'ai une variable Object** object dans Windmill, Object qui est struct avec quelques variables.
Originellement, j'ai dans mon code
object = new Object* [list_object_length];
J'ai remplacé delete[] par free() mais j'ai la même erreur _ZdaPv
Ajouté le 01/05/2021 à 16:47 :
Autant pour moi, il fallait chercher un peu
object = (Object**) malloc(list_object_length * sizeof(Object));
Pas facile de jongle entre le C, le C++ et le C# (au boulot)
Citer : Posté le 01/05/2021 16:51 | #
Tu peux toujours faire fxsdk build-fx 2>&1 | c++filt. C'est un peu bourrin mais dans l'ensemble ça va marcher. C'est parce que c++filt cherche dans son entrée standard des noms de fonctions C++ obfusqués et les décode. Tout le texte autour est conservé sans changement. Le plus important est de bien attraper la sortie d'erreur (le descripteur 2) et de l'envoyer vers la sortie standard (le 1) parce que seule la sortie standard est passée à c++filt par le pipe.
Si tu es prêt à modifier un peu ta commande, tu peux aussi remplacer "/Users/olivier/Documents/CASIO/gcc/bin/../lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld" par "sh-elf-ld" via une commande sed en plus de faire c++filt, ce qui répond à une autre de tes questions.
Perso j'ai des alias ffx et fcg pour compiler, peut-être que tu peux avoir un système similaire pour faire tes ajustements sans avoir à taper des commandes à rallonge.
Citer : Posté le 26/05/2021 16:41 | #
Salut,
J'ai essayé de faire un cross-compilateur armv7l ---> SuperH-3 / SuperH-4, et donc j'ai utilisé termux (je précise tout de même que termux supporte à peut près toutes les architectures utilisées par les téléphones).
Déjà GiteaPC fonctionne parfaitement donc ça fait une bonne nouvelle, mais il n'arrivait pas à compiler binutils, tout du moins il générait un warning au sujet d'une fonction non-prototypée (fgets_unlcoked). Du coup j'ai fait un fork de sh-elf-binutils, auquel j'ai d'ailleurs rajouté le système de dépendance avec pkg (le gestionnaire de paquets de termux) et elles y sont toutes exceptée la libppl qui est introuvable (mais qui, au moins pour binutils, ne sert à rien).
Le premier problème était tout bête, la fonction existait mais n'était prototypée dans <stdio.h> qu'en fonction d'une variable de pré-processeur, __ANDROID_API__ qui n'était pas correctement initialisée. Une fois la variable rajoutée dans les CFLAGS et CXXFLAGS, j'ai fait face à deux problèmes :
1. Si je passe CFLAGS et CXXFLAGS en arguments à configure, les anciens "-g et -O2" disparaissent, et je n'ai trouvé aucun moyen de les rajouter de façon correcte sans affecter pleins de variables dans configure.sh. Ce qui m'amène à la question suivante :"À votre avis, sont-ils vraiment nécessaires ?", je précise tout de même que même sans, il n'y a aucune erreur de compilation.
2. Pour revenir sur les dépendances, bison, par exemple, mais c'est le cas pour plein d'autres n'est pas pré-installé, mais le paquet existe, et configure regarde s'il est installé, mais ne génère pas d'erreur(s) donc est-il nécessaire ?
Et au même titre, isl (pkg : libisl) est-il nécessaire, car pour le coup lorsque configure ne le détecte pas, il précise
required isl version is 0.15 or later
mais ne génère toujours pas d'erreur(s).
Je précise aussi que dans termux la commande gcc provient de clang et que gcc classique n'est pas installable en tant que paquet. Même chose pour g++.
Pour conclure sur sh-elf-binutils, j'ai l'impression que l'ajout des dépendances ainsi que la correction de __ANDROID_API__ suffisent à réussir la compilation de ce-dernier tout téléphones confondus, en tout cas j'ai testé sur deux téléphones différents et ça fonctionne sans problème.
Pour ce qui est de compiler sh-elf-gcc (car oui, ça à l'air d'être possible) j'ai fait face à d'autres problèmes :
- Il faut là aussi corriger __ANDROID_API__, mais du coup la même manip semble fonctionner.
- Il y a deux types de warnings extrêmement récurrents,
- Vu que gcc vient de LLVM, il y a des warnings au sujet du fait que __VA_ARGS__ n'est qu'un standard GNU, mais clang ne met pas qu'il n'arrive pas à s'en servir donc je sais pas non plus si c'est réellement un problème.
- Globalement la compilation ne pose aucun problème, mais à un moment, une commande exécutant un certain nouveau fichier (dont j'ai oublié le nom, mais je vais refaire une compilation et le rajouter) résulte en quelque chose du genre : "error: Android 5.0 and above only supports PIE (position independent executables)". Bien entendu mon téléphone est sur android 10 donc je n'ai aucune idée d'où sort ce problème.
Il doit aussi y avoir d'autres problèmes après mais chaque chose en son temps.
Pour ce qui est de pourquoi essayer de le cross-compiler bah à mon avis il y a plusieurs raisons :
1. Si on peut généraliser la compilation à toutes les marques de téléphones sans modifier le code source de gcc (notamment grâce à termux), ça rend le portage beaucoup, beaucoup plus intéressant.
2. Je ne sais pas si c'est la cas d'autres personnes, mais quand je me déplace j'ai tout le temps mon téléphone et je passe déjà le clair de mon temps à coder de trucs en c pour celui-ci, alors pourquoi pas pour ma calculette.
3. J'ai aussi vu que les dev de termux ont réussi à rajouter le paquet libusb sans avoir les autorisations root, du coup peut-être qu'avec la nouvelle maj du fxsdk on pourra communiquer d'un téléphone à la calculette directement.
Merci d'avoir pris le temps de lire mon message, et je lirais vos avis (s'il y en a) avec beaucoup d'attention.
Citer : Posté le 26/05/2021 17:28 | #
Quelle aventure ! J'ai vu passer pas mal de commits mais je ne savais pas que tu avais fait tout ça. Wow !
1. Si je passe CFLAGS et CXXFLAGS en arguments à configure, les anciens "-g et -O2" disparaissent, et je n'ai trouvé aucun moyen de les rajouter de façon correcte sans affecter pleins de variables dans configure.sh. Ce qui m'amène à la question suivante :"À votre avis, sont-ils vraiment nécessaires ?", je précise tout de même que même sans, il n'y a aucune erreur de compilation.
Tu as essayé CFLAGS="-D__ANDROID_API__ -O2" ? Les flags -g et -O2 ne sont jamais nécessaires, mais -g est crucial pour debugger la toolchain et -O2 est crucial pour la vitesse du compilateur à la fin. Honnêtement -g on s'en fout, on debugge pas binutils. Mais -O2 ça paraît important surtout que les téléphones ils n'ont pas un Core i7
Ça c'est un peu au doigt mouillé mais je pense qu'il doit se rabattre sur autre chose. Regarde par exemple s'il n'a pas trouvé (et utilisé) yacc à la place de bison. libisl c'est des trucs type programmation linéaire et polyèdres, libppl aussi. Les deux sont nécessaires pour les optimisations de GCC (ie. une partie de l'option -O sur le compilateur SuperH). Si tu ne les as pas ces optimisations seront probablement désactivées, ce qui n'est pas dramatique surtout quand tu prototypes ; pour une release finale ça peut aider de les avoir (après tu peux compiler tes releases finales sur un PC une fois par mois
Rien d'affolant comme tu t'en doutais.
Tu veux dire ##__VA_ARGS__ non ? C'est sans doute parce que des flags pedantic sont activés, rien de gênant a priori. Ça me fait bien rire cela dit parce qu'une solution standard a été implémentée ensuite (__VA_OPT__) mais Clang ne la supporte pas.
Alors ça par contre c'est chiant. Ton téléphone est sur Android 10, le problème c'est sans doute qu'un fichier non-PIE est en train de se faire exécuter. Je pense que tu sais déjà, mais pour info PIE c'est une forme de code qui peut être chargé à n'importe quelle adresse virtuelle et marcher (ie. il hardcode pas l'adresse où il pense se faire charger). C'est utilisé par les libs dynamiques mais aussi par les exécutables pour une variété de raisons. Si quelque chose en plein milieu de la compilation se fait compiler en non-PIE et qu'il faut le changer, ça risque d'être un peu chiant à faire proprement.
Ça a l'air très intéressant en tous cas ! Mon téléphone est un vieux trucs à peine qualifiable de smartphone, donc c'est quelque chose que je n'ai pas du tout exploré, mais ça a l'air très bien. Je prends les pull requests avec joie quand tu jugeras ça stable !
Citer : Posté le 02/06/2021 17:37 | #
Re-bonjour,
Désolé d'avoir pris des plombes à répondre, j'ai pas d'excuse.
Tu as essayé CFLAGS="-D__ANDROID_API__ -O2" ?
Effectivement ça fonctionne très bien, c'est juste que je voulais rester avec le même genre de truc que ce qui a été fait avec sh-elf-gcc et $extra_args : "../gcc-$VERSION/configure --prefix="$PREFIX" --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --enable-languages=c,c++ --without-headers --with-newlib --program-prefix=sh-elf- --enable-libssp --enable-lto $extra_args".
Pour libisl, libppl, bison etc... j'ai pas mis libisl et libppl parce qu'il y à un gros problème avec gcc (j'en parle dans la suite du message), et pour bison/yacc aucune idée parce que dans termux les deux réfèrent au même paquet, qui n'est pas installé.
Tu veux dire ##__VA_ARGS__ non ?
Tout à fait.
Alors ça par contre c'est chiant. Ton téléphone est sur Android 10, le problème c'est sans doute qu'un fichier non-PIE est en train de se faire exécuter. Je pense que tu sais déjà, mais pour info PIE c'est une forme de code qui peut être chargé à n'importe quelle adresse virtuelle et marcher (ie. il hardcode pas l'adresse où il pense se faire charger). C'est utilisé par les libs dynamiques mais aussi par les exécutables pour une variété de raisons. Si quelque chose en plein milieu de la compilation se fait compiler en non-PIE et qu'il faut le changer, ça risque d'être un peu chiant à faire proprement.
Effectivement c'est chiant, vraiment.
J'ai essayé pas mal de trucs pour empêcher la compilation avec no-pie et fno-pie, mais j'ai pas réussi juste avec des flags, et aller trifouiller le configure tiendra jamais entre les versions; qui plus est ce n'est apparemment pas compilé en non-PIE pour rien (j'ai pas tout saisi, mais ça ne fonctionne pas sans semble-t-il). J'avoue que ça me soûle, et ça explique pourquoi termux utilise clang et pas gcc, pour les citer
# Replace gcc since gcc is deprecated by google on android and is not maintained upstream.
===> Conclusion de ce message un peu défaitiste :
Pour ce qui est de sh-elf-binutils, ça fonctionne du feu de dieu, en tout cas j'ai essayé sur deux téléphones différents (ceci dit les deux étaient sur la même architecture, armv7l et android>=10), ainsi que sur deux émulations (PrimeOS et Anbox, en x86_64, et tout deux android 7.1 je crois), et ça fonctionne tout autant (mini problème de dépendances pour PrimeOS et Anbox avec libxml2 et clang mais c'est patché, peut-être pas tout de suite, s'il faut du temps pour que les dépôts s'actualisent, mais en tout cas elle a été rajoutée donc ce n'est qu'une question de temps). À priori avant Android 7 ça ne fonctionnera pas car termux a un clivage de ses dépôts entre Android<7 et Android>=7 donc il manquerait des dépendances.
À propos de dépendances, libppl c'est mort, parce que le paquet n'est plus maintenu donc il ne sera pas rajouté dans les dépôts, et de toutes façons sa compilation dépend des habilités du processeur donc je sais pas si on peut en faire un paquet (au passage j'arrive même pas à la compiler). Donc c'est vrai que si on avait pu avoir sh-elf-gcc ça aurait été utile de faire les releases sur un ordi.
Et enfin pour sh-elf-gcc, le portage (propre et qui tient dans le temps) est purement impossible, donc à priori ça tombe à l'eau.
J'ai pas de solutions, excepté utiliser clang comme cross-compilateur, mais (j'ai l'impression qu') il n'a pas l'air de supporter sh3eb et sh4a (si je dis pas de bêtises) comme cible. En tout cas catégorie RISC-V (32-bits) il y a ça :
'generic-rv32;generic-rv64;rocket-rv32;rocket-rv64;sifive-7-rv32;sifive-7-rv64;sifive-e31;sifive-e76;sifive-u54;sifive-u74'
Sincèrement je suis pas là pour demander à ce que quelqu'un s'embête à trouver comment faire avec clang (même si ça m'arrangerait
Citer : Posté le 02/06/2021 17:52 | #
Ah mais tu peux rajouter ce genre d'options sans hésiter, je le mergerais sans broncher. Si ça marche le script suivra.
Ce n'est pas un problème de GCC ça, c'est un problème du système de build qui rajoute des options au fur et à mesure et qui ne te permet pas de changer ce que tu veux.
N'oublie pas qu'il faut à la fois CFLAGS += -fPIC et LDFLAGS += -pie pour avoir des exécutables PIE à tous les coups. N'hésite pas à vérifier dans quel ordre les flags arrivent dans la commande de compilation.
Bien joué ! o/
LLVM n'a pas de backend SuperH donc oui GCC est la seule option ! Faire marcher Clang pour ça est 10 fois plus impossible que modifier le système de build de GCC pour être honnête.
Citer : Posté le 02/06/2021 18:13 | #
Dommage
En vrai c'est pas très grave je m'y attendais.
Pour les CFLAGS et LDFLAGS j'ai déjà essayé mais ça fonctionne pas, ils sont mis au tout début et no-pie/fno-pie à la toute fin (de la commande qui pose problème, même si en fait elles sont un certain nombre). J'ai vu un certain NO_PIE_FLAG et NO_PIE_CFLAG passer mais si je me souviens bien les modifier durant la configuration ne fonctionne pas (ils sont remis à no-pie et fno-pie). Pareil durant le build.
Du coup je vais essayer d'autres trucs (enfin bon je promets rien), mais je risque de refaire comme la dernière fois et répondre avec une semaine de retard
Citer : Posté le 18/06/2021 10:03 | #
Bonjour
J'ai un problème de compilation en utilisant le paquet sh-elf-gcc-casio de l'AUR sur Arch Linux (après que sh-elf-binutils-casio se soit installé correctement).
J'ai rencontré ce problème sur deux pc arch linux différents (mais c'est sûrement de ma faute, je gère souvent mes PC d'une manière pas très intelligente..)
Est-ce que quelqu' un saurait à quoi c'est dû?
Merci à vous!
mkdir -p -- .deps
make[1] : on entre dans le répertoire « /home/benoit/yay/sh-elf-gcc-casio/src/gcc-11.1.0/gcc-build/build-x86_64-pc-linux-gnu/libcpp »
g++ -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../../libcpp/charset.c
g++ -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -c -o directives.o -MT directives.o -MMD -MP -MF .deps/directives.Tpo ../../../libcpp/directives.c
g++ -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -c -o errors.o -MT errors.o -MMD -MP -MF .deps/errors.Tpo ../../../libcpp/errors.c
g++ -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcpp/include -c -o expr.o -MT expr.o -MMD -MP -MF .deps/expr.Tpo ../../../libcpp/expr.c
../../../libcpp/expr.c: Dans la fonction « unsigned int cpp_classify_number(cpp_reader*, const cpp_token*, const char**, location_t) »:
../../../libcpp/expr.c:811:35: erreur: le format n'est pas une chaîne littérale et il n'y a pas d'arguments de format [-Werror=format-security]
811 | cpp_warning_with_line (pfile, CPP_W_LONG_LONG, virtual_location,
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
812 | 0, message);
| ~~~~~~~~~~~
../../../libcpp/expr.c:814:38: erreur: le format n'est pas une chaîne littérale et il n'y a pas d'arguments de format [-Werror=format-security]
814 | cpp_pedwarning_with_line (pfile, CPP_W_LONG_LONG,
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
815 | virtual_location, 0, message);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../libcpp/expr.c:824:33: erreur: le format n'est pas une chaîne littérale et il n'y a pas d'arguments de format [-Werror=format-security]
824 | cpp_warning_with_line (pfile, CPP_W_SIZE_T_LITERALS,
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
825 | virtual_location, 0, message);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus : certains avertissements sont traités comme des erreurs
make[1]: *** [Makefile:226 : expr.o] Erreur 1
make[1] : on quitte le répertoire « /home/benoit/yay/sh-elf-gcc-casio/src/gcc-11.1.0/gcc-build/build-x86_64-pc-linux-gnu/libcpp »
make: *** [Makefile:2906 : all-build-libcpp] Erreur 2
==> ERREUR : Une erreur s’est produite dans build().
Abandon…
Citer : Posté le 18/06/2021 10:10 | #
Aaah ! Ça c'est un problème bien chiant dans toute sa splendeur. Je m'explique. autoconf, l'outil utilisé pour générer les commandes de compilation des fichiers de GCC, décide depuis une certaine version d'activer -Werror=format-security, qui transforme en erreurs tous les warnings sur les formats printf/etc qui ont l'air non sécurisés. Le problème c'est qu'à un moment GCC a ajouté un warning dans cette catégorie, ce qui crée des erreurs dans un code qui marchait bien jusque-là ; comme l'activation de l'option dépend de la distribution (Arch) ou autre chose, les devs s'en sont pas rendus compte, et on se retrouve avec un logiciel qui ne compile plus. Soit dit en passant tous ces warnings sont superflus, il suffit de regarder la ligne de dessus pour voir qu'il n'y a pas de risque.
En bref, pour Darks, la solution est d'exporter un truc du style
export CXXFLAGS="$CXXFLAGS -Wno-error -Wno-error=format-security"
avant de faire configure/make dans le paquet. J'ai résolu un problème ou deux comme ça.
Citer : Posté le 18/06/2021 10:35 | #
Merci!
J'ai ajouté ces deux lignes avant le prepare() du PKGBUILD, et les erreurs sont devenues des Warnings