Introduction à QtWebEngine
QtWebEngine intègre les
composantes web de chromium dans
Qt. Il contient sa propre copie de ninja qu'il utilise lors de la
construction s'il ne peut pas trouver une copie sur le système, et
diverses copies de bibliothèques de ffmpeg, icu, libvpx et zlib
(dont libminizip) qui ont été forkées par les développeurs de
chromium.
Ce paquet et les navigateurs qui l'utilisent peuvent être utiles si
vous utilisez un site conçu pour google chrome, ou chromium.
![[Avertissement]](../images/warning.png)
Avertissement
QtWebEngine utilise une copie forkée de chromium, et est donc
vulnérable à plusieurs problèmes qui y ont été trouvés. Les
développeurs de Qt ont toujours préféré publier en même temps que
le reste de Qt (plutôt que d'ajouter des corrections en urgence),
mais les versions stables sont publiée après la version de
développement actuelle. Maintenant qu'ils se préparent à passer à
Qt6, les version 5.15.3 et les versions suivantes de Qt-5.15 ne
sont initialement disponibles que pour leurs clients. QtWebEngine
est un peu une exception avec sa licence LGPL, mais récupérer les
sources git (avec le sous-module chromium forké) et l'amener à un
point où il est possible de le compiler sur un système BLFS
récent peut demander beaucoup d'effort et les mises à jour du
livre peuvent être retardées.
Il semble que les futures versions de la série 5.15 seront aussi
publiées bien après que les vulnérabilités de chromium ne soient
connues, mais les corrections de QtWebEngine se trouvent dans le
dépôt git et les rédacteurs pensent que les vulnérabilités
connues des navigateurs devraient être corrigées.
L'archive proposée ci-dessous a été créée à partir de la branche
git 5.15 et la branche 87 du sous-module chromium (qui est une
version forkée de chromium). Voir le fichier GIT-VERSIONS dans
l'archive pour des détails sur les derniers commits.
![[Note]](../images/note.png)
Note
Development versions of BLFS may not build or run some packages
properly if dependencies have been updated since the most recent
stable versions of the book.
Avertissement
Par défaut, ninja utilisera tous les CPU actifs + 2 (si au moins
4 existent), même s'ils ne sont pas disponibles pour la tâche
actuelle parce que le terminal a été restreint avec
« taskset ». Dans BLFS, ce paquet prend plus de temps à
construire que n'importe quel autre. Une fois, la construction de
ce paquet a échoué à environ 90 pourcent à cause d'un problème de
mémoire sur un système à 24 cœurs et 32 Go de mémoire.
Pour contourner cela, voir les explications des commandes
ci-dessous.
Note
Si vous mettez à jour et avez installé une nouvelle version de
ICU-71.1 depuis la dernière installation de
Qt-5.15.5,
vous devrez réinstaller Qt5 avant la mise à jour, sinon la
liaison finale de ce paquet échouera avec un avertissement
indiquant que la version des bibliothèques icu requises par
libQt5Core.so peuvent entrer en conflit avec la version utilisée
par ce paquet.
De manière inhabituelle, le système de construction GN intégré
(utilisé pour créer les fichiers Ninja) a besoin d'une version
statique de libstdc++.a bien que
les bibliothèque installées utilisent bien la version partagée.
Si cette bibliothèque statique n'est pas présente, la
construction échouera rapidement. Remarquez que si vous essayez
de construire webengine en tant que partie de Qt et que la bibliothèque statique n'est pas
disponible, cette construction terminera sans installer webengine
ou échouera pendant l'installation (les deux comportements ont
été observés en 5.12.0).
Informations sur le paquet
Téléchargements supplémentaires
Dépendances de qtwebengine
Requises
nodejs-16.16.0, nss-3.81, pciutils-3.8.0 et Qt-5.15.5
Recommandées
Note
Si ces paquets ne sont pas installés, le processus de
construction compilera et installera ses propres (sans doute plus
vieilles) versions, avec pour effet d'augmenter l'espace disque
utilisé et le temps pris par la construction et l'installation.
soit alsa-lib-1.2.7.2 soit PulseAudio-16.1 (ou les deux), FFmpeg-5.1, ICU-71.1 (construit
avant libxml2-2.9.14), libwebp-1.2.3,
libxslt-1.1.35 et Opus-1.3.1
Facultatives
libevent-2.1.12, MIT Kerberos
V5-1.20, pipewire-0.3.54, Poppler-22.08.0, jsoncpp,
libsrtp, snappy
Notes utilisateur : https://wiki.linuxfromscratch.org/blfs/wiki/qtwebengine
Installation de qtwebengine
Appliquez un correctif pour corriger plusieurs problèmes qui
empêchent la construction et pour la forcer à utiliser
python3 :
patch -Np1 -i ../qtwebengine-5.15.10-build_fixes-1.patch
Apply a patch that resolves problems when building with ffmpeg-5:
patch -Np1 -i ../qtwebengine-5.15.10-ffmpeg5_fixes-1.patch
Bien que le correctif build_fixes s'assure que git n'est pas appelé
pendant la construction, le système de construction a des règles
labyrinthiques d'une extrême complexité, et en particulier essayer
de construire sans les deux répertoires .git le fera échouer à construire un code
inattendu et inconstructible qui référence un en-tête privé qui n'a
pas été généré. Évitez cela en créant les répertoires requis :
mkdir -pv .git src/3rdparty/chromium/.git
Comme cette version de qtwebengine est conçue pour une version plus
récente que la version publique actuelle, changez-la pour
construire pour qt-5.15.5 avec un sed :
sed -e '/^MODULE_VERSION/s/5.*/5.15.5/' -i .qmake.conf
Maintenant, assurez-vous que les en-têtes locaux sont disponibles
lorsque vous ne construisez pas ce paquet en tant que partie de
Qt-5.15.5 :
find -type f -name "*.pr[io]" |
xargs sed -i -e 's|INCLUDEPATH += |&$$QTWEBENGINE_ROOT/include |'
Ensuite, permettez à la bibliothèques pulseaudio de se lier à la
construction, plutôt qu'à l'exécution. Cela évite un problème avec
les nouvelles versions de pulseaudio :
sed -e '/link_pulseaudio/s/false/true/' \
-i src/3rdparty/chromium/media/media_options.gni
Enfin, corrigez un changement dans le système de construction qui
permet à ses développeurs de passer par exemple -j20 à make (pour
des tests rapides de certains composants) mais casse la
construction quand LFS utilise la variable d'environnement
NINJAJOBS :
sed -i 's/NINJAJOBS/NINJA_JOBS/' src/core/gn_run.pro
Installez qtwebengine en exécutant
les commandes suivantes :
mkdir build &&
cd build &&
qmake .. -- -system-ffmpeg -webengine-icu &&
make
Ce paquet n'a pas de suite de tests.
Maintenant, en tant qu'utilisateur root :
make install
Supprimez les références au répertoire de construction dans les
bibliothèques de dépendances (prl) installées en exécutant les
commandes suivantes en tant qu'utilisateur root :
find $QT5DIR/ -name \*.prl \
-exec sed -i -e '/^QMAKE_PRL_BUILD_DIR/d' {} \;
Explication des commandes
qmake : Ceci
construira la copie embarquée de ninja si elle n'est pas déjà installée et
l'utilisera pour configurer la construction.
-- -system-ffmpeg
-webengine-icu : Si des options sont passées à
qmake elles doivent apparaître après « -- » qui doit
suivre les « .. » qui pointent vers le répertoire
principal. Les options lui font utiliser les paquets ffmpeg et icu
du système. Si vous le construisez en tant que partie de Qt5, le
paquet icu du système est automatiquement utilisé (seulement) par
Qt5Core s'il est disponible, mais à moins que vous utilisiez cette
option webengine utilisera toujours la copie incluse de icu, ce qui
demande plus de temps et d'espace pour la construction.
-webengine-jumbo-build 0 : si
ajoutez cela à la commande qmake cela causera le rapport de
« Jumbo Build Merge Limit » à « no » au lieu de
8. Cela désactive la construction lourde. Certaines distributions
utilisent cela pour une construction plus légère sur certaines
architectures comme MIPS. Sur x86_64 cela peut faire gagner un peu
de place pendant la construction, mais le temps de construction
augmentera énormément.
-webengine-kerberos : ajoutez cela
si vous avez installé MIT Kerberos V5-1.20 et souhaitez
vous connecter à partir d'un navigateur QtWebEngine à un serveur
web qui vous demande de vous connecter par kerberos.
NINJAJOBS=4 make : Si vous avez
corrigé le ninja du système dans LFS pour qu'il reconnaisse la
variable d'environnement NINJAJOBS, cette commande lancera le ninja
du système avec le nombre de travaux spécifiées (c.-à-d. 4). Il y a
plusieurs raisons pour lesquelles vous pourriez vouloir faire
cela :
-
Construire sur un sous-ensemble des CPU permet de mesurer le
temps de construction pour un plus petit nombre de
processeurs, et de lancer d'autres tache gourmandes en CPU en
même temps. Pour les rédacteurs sur une machine avec de
nombreux CPU, qui essayent de mesurer le temps pour une
machine à 4 cœurs, NINJAJOBS=4
make donnera une approximation raisonnable (il y a une
petite période où N+2 travaux python2 et node tournent en
même temps).
-
Sur une machine avec seulement 4 CPU en ligne,
l'ordonnancement de N+2 taches pour qtwebengine est plus lent
d'environ 3 à 7 %, sans doute à cause de la taille des
fichiers C++ et de leurs nombreux fichiers inclus et modèles.
Donc, dans le doute paramétrez NINJAJOBS aux nombre de CPU.
-
Réduire le nombre de cœurs utilisé pour des paquets gourmands
en CPU pendant un long moment peut atténuer des problèmes de
température.
-
Réduire le nombre de coùrs évitera d'éventuels problèmes de
mémoire sur les systèmes qui n'ont pas suffisamment de
mémoire (ou d'espace d'échange) quand tous les cœurs sont
actifs. L'approche suggérée est de limiter le nombre de cœurs
à environ un pour chaque 1,5 Go de RAM et d'espace d'échange
combinés.