Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Vos tutoriels et astuces


Index du Forum » Vos tutoriels et astuces » [Tutoriel] Installation manuelle de GCC (et du fxSDK)
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

[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.

[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


Précédente 1, 2, 3 ··· 10 ··· 20, 21, 22, 23, 24, 25 Suivante
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

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.
Kamrade Hors ligne Membre Points: 48 Défis: 0 Message

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!
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

Citer : Posté le 04/04/2021 19:10 | #


Salut Lephé !
Dans le tuto
Lephénixnoir a écrit :
Enfin, --program-prefix permet de donner un nom personnalisé au compilateur, ici sh-elf-gcc.
Il est pourtant écrit dans le bout de code --program-prefix=sh-elf- sans le gcc à la fin, c'est normal ?
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

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).
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

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 :
make: *** No rule to make target all-gcc'. Stop.[/quote]
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 ?
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

Citer : Posté le 04/04/2021 20:44 | #


Ton configure a dû échouer quelque part, c'est « trop gros » comme erreur.
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

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"
Warning: mpc 0.33 is already installed and up-to-date.

Il y a un sacré écart de version là entre 0.33 et 0.8 !
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

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)
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

Citer : Posté le 04/04/2021 22:00 | #


C'était bien ça ! Merci
Avensis Hors ligne Membre Points: 23 Défis: 0 Message

Citer : Posté le 25/04/2021 12:15 | #


Salut, merci pour le partage c'est vraiment génial
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

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 ?
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

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 :

% echo __ZN8Windmill8load_mapEP3Map | 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.
Ninestars Hors ligne Membre Points: 2449 Défis: 24 Message

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
delete[] object;
object = new Object* [list_object_length];
Comment je peux modifier en conséquence ?
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
free(object);
object = (Object**) malloc(list_object_length * sizeof(Object));


Pas facile de jongle entre le C, le C++ et le C# (au boulot)
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

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.
Sales Hors ligne Membre Points: 5 Défis: 0 Message

Citer : Posté le 25/05/2021 22:36 | #


ça marche pour moi merci pour le partage
Neiviv-ui Hors ligne Membre Points: 29 Défis: 0 Message

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
checking for isl 0.15 or later... no
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,
'__ANDROID_API__' macro redefined
et
unknown warning option '-Wshadow=local'
qui pullulent durant la compilation, mais en tant que tel ça ne pose pas problème.
- 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.
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

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 !

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.

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

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 ?

Ç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 ).

- Il y a deux types de warnings extrêmement récurrents,

Rien d'affolant comme tu t'en doutais.

- 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.

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.

- 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.

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 !
Neiviv-ui Hors ligne Membre Points: 29 Défis: 0 Message

Citer : Posté le 02/06/2021 17:37 | #


Re-bonjour,
Désolé d'avoir pris des plombes à répondre, j'ai pas d'excuse.
Lephenixnoir a écrit :
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é.

Lephenixnoir a écrit :
Tu veux dire ##__VA_ARGS__ non ?

Tout à fait.

Lephenixnoir a écrit :
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
Les devs de termux a écrit :
# Replace gcc since gcc is deprecated by google on android and is not maintained upstream.
donc je vois vraiment pas comment je peux faire quelque chose si eux n'y arrivent pas.


===> 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 ), et puis on sort complètement du cadre de giteapc, c'est juste que ça m'intéresse.
Lephenixnoir En ligne Administrateur Points: 22599 Défis: 149 Message

Citer : Posté le 02/06/2021 17:52 | #


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

Ah mais tu peux rajouter ce genre d'options sans hésiter, je le mergerais sans broncher. Si ça marche le script suivra.

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

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.

Pour ce qui est de sh-elf-binutils, ça fonctionne du feu de dieu

Bien joué ! o/

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.

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.
Neiviv-ui Hors ligne Membre Points: 29 Défis: 0 Message

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 .
Palpatine_78 Hors ligne Membre Points: 264 Défis: 0 Message

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!

config.status: executing depdir commands
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…
Précédente 1, 2, 3 ··· 10 ··· 20, 21, 22, 23, 24, 25 Suivante

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2022 | Il y a 74 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd