Sommaire
- L'environnement hôte
- Parce que c'est pas encore assez fun, les pilotes graphiques de Raspberry Pi
- Compilation de Qt…
- Bande de zapotèques !
- Supplément de mensonges
Salut à tous
Après avoir passé… «plusieurs heures» pour obtenir un QtWebEngine qui fonctionne sous raspbian, je me suis dit qu'il serait peut-être intéressant de partager l'expérience ici. À la fois pour le côté scientifique, documentaire de la chose, mais aussi tout simplement pour vider mon sac, parce qu'on en a gros. Puis ça fait longtemps que j'ai pas fait de journal, ça me manque…
Tout d'abord, petite observation : sur les dépôts raspbian, on trouve beaucoup de paquets… normal, c'est un dérivé de debian me direz-vous ? Non non, même des vieilleries genre Qt 3 sont encore là, sorti 8 ans avant la première Raspberry Pi…
Mais par contre des fois y'a des trous. Genre quand on veut afficher une page web, la techno officielle de Qt est WebEngine, dérivé de Chromium (suite à la direction prise par Apple dans Webkit à l'époque de la version '2.0'). Et là, ben on n'a pas grand chose : on a la doc, les données, mais pas la lib.
Du coup, petite histoire de cross-compilation (compiler blink sur une raspberry pi me semble être une très mauvaise idée) et de souffrance, accrochez vous.
L'environnement hôte
Alors, j'utilise une debian pour cela. Attention : il faut une debian inférieure ou égale à la version raspbian ciblée pour utiliser le compilateur packagé par Debian. Je m'explique. Quand on va compiler sur mettons une debian sid, même si on réalise une cross-compilation vers raspbian, certains composants vont venir du compilateur lui-même, et donc être liées à la version de la libc de debian.
Démonstration:
snoopy@peanuts2:/tmp$ cat math.cpp
#include <cmath>
int test(int a, int b) {
return pow(a, b);
}
snoopy@peanuts2:/tmp$ arm-linux-gnueabihf-g++ math.cpp -shared -o math.so
snoopy@peanuts2:/tmp$ arm-linux-gnueabihf-nm math.so | grep pow
U pow@@GLIBC_2.29
Donc déjà vous avez perdu 5 points de santé mentale en ayant configuré toute votre machine pour la cross-compilation, tout installé, vérifié et tout… pour au final vous rendre compte que votre binaire ne pourra pas marcher. (Évidemment je m'en suis rendu compte avec mon Qt complet, pas avec un exemple d'une ligne)
Du coup, on reprend, l'environnement hôte… Il suffit d'installer les paquets gcc-arm-linux-gnueabihf et g++-arm-linux-gnueabihf et votre debian buster devrait normalement être à même de produire des binaires compatibles avec raspbian buster.
Ensuite, deuxième étape : il vous faut une raspbian sur votre debian. Pas exécutable (encore que, avec qemu… bref), mais juste l'arborescence pour avoir les fichiers d'en-tête, les bibliothèques dans les bonnes versions…
Du coup, il faut préparer une raspbian. Je vous invite à suivre https://wiki.qt.io/RaspberryPi2EGLFS mais pas trop. Jusqu'à l'étape 9, tout va presque bien…
Parce que c'est pas encore assez fun, les pilotes graphiques de Raspberry Pi
La Pi <4 dispose, pour sa puce graphique VC4, de deux pilotes: le pilote libre vc4, intégré au noyau, et le pilote propriétaire brcm. N'utilisez pas le pilote propriétaire pour cet usage. Il impose un vieux GCC qui n'est pas compatible avec les webengine récents… (j'ai pleuré du sang sur cette blague là)
Du coup, on suit pas exactement le tuto. Dans raspi-config, dans le choix du pilote GL, il faut utiliser le «OpenGL desktop driver» (à vous le choix fake KMS vs full KMS, ça dépend de votre écran et de comment il est connecté… 3 points de santé mentale en moins)
Ensuite seulement, on peut reprendre la documentation de Qt pour obtenir un sysroot viable.
Compilation de Qt…
Je vous invite à prendre directement les archives complètes plutôt que les modules individuels depuis git. C'est bien plus simple, surtout quand ça inclut un monstre comme WebEngine (au moins 30 minutes de git clone chez moi). Du coup je suis parti de https://download.qt.io/official_releases/qt/5.12/5.12.6/single/qt-everywhere-src-5.12.6.tar.xz.mirrorlist
Tout d'abord, le configure…
./configure -release -opengl es2 -device linux-rasp-pi3-vc4-g++ -device-option CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -sysroot /opt/raspi/sysroot.vc4 -opensource -confirm-license -make libs -prefix /usr/local/qt5pi -extprefix /opt/qt5pi/5.12.6/build -hostprefix /opt/qt5pi/5.12.6/tools -no-xcb -no-use-gold-linker -v -nomake examples -nomake tests -libinput -libudev -webengine-proprietary-codecs
Ce sont mes options, libre à vous d'en changer évidemment. Décomposons…
-release : pas de debug (sinon c'est beaucoup plus lourd)
-device linux-rasp-pi3-vc4-g++ -device-option CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -sysroot /opt/raspi/sysroot.vc4 : on vise une raspberry pi 3, pilote vc4, et on utilise le compilateur de notre debian
-opensource -confirm-license : on est sur la version libre, et oui on a lu la licence
-prefix /usr/local/qt5pi -extprefix /opt/qt5pi/5.12.6/build -hostprefix /opt/qt5pi/5.12.6/tools : on installera dans /usr/local/qt5pi sur la Pi, et dans /opt/qt5pi/5.12.6 sur la machine hôte (j'ai pris là où j'avais de la place)
-no-xcb : je vise de l'embarqué, donc pas de X11
-nomake examples -nomake tests : on va économiser quelques minutes de compilation quand même
-no-use-gold-linker : parce que j'ai pleuré sans (encore des points de santé mentale en moins)
-libinput -libudev -webengine-proprietary-codecs : des options dont j'ai besoin pour mon usage
Et on compile tout ça, avec un make -j 42 (remplacez 42 par le nombre de CPU×2+âge du capitaine-5)… on va prendre moultes thés, cafés, cachets d'opium… et on revient : hoo, il a compilé !
Tout fièrement, on fait make install… on regarde… Hooo, il n'a pas compilé QtWebEngine, le petit cachotier…
Bande de zapotèques !
Nous arrivons à la blague ultime. Vraiment balaise.
Tout d'abord, le configure de Qt n'est pas très précis et ne dit pas clairement que non non, le QtWebEngine ne passe pas.
Et ce qui m'a le plus bloqué et rendu fou n'est pas lié à Qt mais à WebEngine. Pour compiler blink en ciblant de l'ARM 32 bits, si on est sur une machine x86 64 bits, il faut avoir le nécessaire pour compiler du x86 32 bits.
Oui oui. Pour compiler pour l'architecture A, si on est sur une architecture B, il faut aussi pouvoir compiler pour l'architecture C. J'étais fou de rage sur celle là.
Ha oui, il utilise aussi son propre système de build lancé depuis make. Parce que c'est plus fun. Et puis des fois il se plante et veut voir les libs sur le système hôte au lieu de chercher dans le système cible.
Du coup, j'ai installé les paquets suivants sur mon hôte pour que ça passe:
apt install ninja-build lib32stdc++-8-dev libnss3-dev
Et là, après environ 4 heures de compilation, là c'est passé.
Supplément de mensonges
Y'a une petite blague dans ce que j'ai dit au dessus, que je placerais à 10 sur l'échelle de la puputerie : il utilise aussi son propre système de build lancé depuis make.
Ils ont choisi d'utiliser ninja… Soit, ok, si vous voulez. Mais ninja est vachement fort, il peut lancer autant de jobs en parallèle qu'il y a de CPU… Bonne idée direz-vous ?
J'ai fait un OOM avant d'aller patcher les Makefile pour forcer ninja à utiliser moins de taches de compilation en parallèle. Blink est un monstre à compiler, les fichiers demandent rapidement des GB de RAM pour compiler. Donc un conseil : activez de la swap, ou utilisez une machine avec moulte espace (j'ai que 16GB sur mon PC perso, et pas mal d'outils qui tournent déjà et réduisent à moins de 10GB la RAM dispo)
Merci à vous d'avoir lu mes heures de souffrance. Vous pouvez maintenant faire un navigateur embarqué sur votre Pi, sans utiliser X11, directement sur le framebuffer. Bon, je vous conseille quand même de faire les interfaces en QML, c'est quand même largement plus performant vu que c'est fait pour (y'a quand même des boites qui développent des moteurs HTML conçus exprès pour ce genre d'usage, genre https://www.ekioh.com/flow-browser/ mais c'est pas libre et y'a même pas une démo téléchargeable)
# Et l'utilisation…
Posté par Pinaraf . Évalué à 4.
J'oubliais, comment utiliser notre Qt cross-compilé ? C'est très simple, il suffit d'utiliser le qmake du dossier /opt/qt5pi/5.12.6/tools, donc
/opt/qt5pi/5.12.6/tools/bin/qmakePour les projets à base de cmake, il faut utiliser le dossier /opt/qt5pi/5.12.6/build/lib/cmake/ qui contient l'ensemble des éléments requis pour qu'il comprenne ce qu'il se passe…
# Un monstre libre l'est-il vraiment ?
Posté par anaseto (site web personnel) . Évalué à 4.
Honnêtement, quand je vois ces monstres, je me dis que le logiciel a beau être libre, s'il faut avoir une machine monstre équivalente pour le modifier et le compiler, en pratique ça veut dire que pas mal d'utilisateurs (moi inclus) ne peuvent pas disposer en pratique d'une des libertés fondamentales. À mon avis, c'est plus grave que de ne pas pouvoir modifier par manque de compétences, car c'est une contrainte plus matérielle, même si je conçois qu'on puisse les considérer similaires : dans les deux cas, du moment qu'il y a des gens à qui tu fais confiance qui ont les moyens, tu profites indirectement des libertés et sinon t'es piégé.
Enfin, pour s'effrayer davantage, heu, je veux dire, se rassurer, dis-toi que ça aurait pu être pire que dans ton cas : sur OpenBSD il y a une multitude de patchs pour porter chromium, j'ai l'impression que les faire remonter upstream c'est pas évident (pas suivi l'histoire, mais ça fait un moment que c'est comme ça) et comme qt5 webengine n'utilise pas exactement la même version de chromium, personne n'a encore eu le courage d'essayer d'adapter les patches, ce qui fait qu'on a toujours pas qt5 webengine, même si j'imagine que ça finira peut-être par arriver.
[^] # Re: Un monstre libre l'est-il vraiment ?
Posté par ʭ ☯ . Évalué à 2.
Bof, alors je peux dire que rien n'est libre puisque je peux pas le compiler sur mon i386SX…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Un monstre libre l'est-il vraiment ?
Posté par anaseto (site web personnel) . Évalué à 2.
Tu peux :-) Après, la question, c'est est-ce que tu as une alternative raisonnablement accessible dans laquelle tu pourrais avoir ces libertés.
Vu qu'un des buts de base logiciel libre à la base, c'est que ce soit l'utilisateur qui ait le contrôle sur le logiciel, on peut pas espérer capturer à fond cette notion avec simplement une licence. Dans certains cas, quand ce contrôle devient difficile pour beaucoup du fait de contraintes non-bureaucratiques (matérielles ou manque de main d'œuvre compétente) et que le logiciel (navigateur web) devient néanmoins indispensable même pour des taches administratives publiques, on peut s'inquiéter. Surtout quand il n'y a pas grand espoir de voir apparaître des alternatives accessibles à court ni peut-être même moyen terme (trop complexe).
[^] # Re: Un monstre libre l'est-il vraiment ?
Posté par barmic 🦦 . Évalué à 2.
Tu sais c'est le cas aussi de logiciels respectables. Il y a longtemps j'ai eu lemmême genre de problème avec OOo (bien avant l'arrivée de LibO) et avec Firefox.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Un monstre libre l'est-il vraiment ?
Posté par anaseto (site web personnel) . Évalué à 2.
Ah, mais je ne voulais pas sous-entendre que c'était parce que le logiciel ne serait pas respectable : pour autant qu'on puisse en juger, personne fait exprès de rendre les choses impossibles à compiler, c'était juste pas une priorité (normal, les devs actuels ont l'infrastructure qu'il faut) et maintenant inverser la tendance semble difficile.
Firefox est bien sûr un monstre également de ce point de vue, bien qu'au moins on dirait qu'il faut moins de patches pour le rendre portable.
[^] # Re: Un monstre libre l'est-il vraiment ?
Posté par claudex . Évalué à 6.
Après, actuellement, ça va te coûte quelques dollars de faire tourner une machine avec 30Go de RAM et assez de disque pour compiler ça. Si tes modifications ne nécessitent pas une recompilation complète, tu peux t’en servir pour compiler une première fois et après récupérer les source précompilée pour faire tes patchs. Ce n’est pas l’idéal mais ça me semble moins problématique qu’à l’époque d’OpenOffice où c’était plus cher et plus compliqué de faire le même setup.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un monstre libre l'est-il vraiment ?
Posté par barmic 🦦 . Évalué à 1.
Pour les patchs de blink c'est assez particulier entre blink qui utilise beaucoup les spécificités du système pour la perf et la sécurité et OpenBSD qui ont leur propre règles de codage (par exemple ne pas utiliser
malloc(3)).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Docker ?
Posté par pmoret (site web personnel) . Évalué à 2. Dernière modification le 01 décembre 2019 à 12:49.
Pour cross-compiler certains environnements il exsite des images docker qui incluent la configuration et les libs nécessaires, est-ce que ça peut être une option pour cas-là ?
Je n'ai pas d'expérience avec Qt, mais j'ai testé récemment de cross-compiler du Rust pour raspberry PI, il y a un projet qui permet de le faire très facilement: https://github.com/rust-embedded/cross est-ce qu'il y aurait des équivalents pour Qt ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.