Introdução ao QtWebEngine
"QtWebEngine" integra os recursos
"web" do "chromium" no "Qt". Ele
vem com a própria cópia dele do "ninja", a qual usa para a
construção se não conseguir encontrar uma cópia de sistema, e
várias cópias de bibliotecas originárias do "ffmpeg", "icu",
"libvpx" e "zlib" (incluindo "libminizip"), as quais foram
bifurcadas pelos(as) desenvolvedores(as) do "chromium".
Esse pacote, e os navegadores que o usam, possivelmente seja útil
se você precisar usar um sítio da "web" projetado para navegadores
"Chrome" ou "Chromium" da "Google".
Importante
Qt-5.15 atingiu o fim da vida útil em 26 de maio de 2023. Qt5.15
LTS vida útil estendida foi estendido até 26 de maio de 2025 para
aqueles(as) com licenças de assinatura. Como o qtwebengine usa
código do chromium sob a LGPL, parece que quaisquer novas
correções CVE implementadas para o QtWebEngine estarão
disponíveis depois que o Qt fizer lançamentos públicos das
versões atuais dele.
Atenção
"QtWebEngine" usa uma cópia bifurcada do "Chromium" e, portanto,
é vulnerável a muitos problemas encontrados lá. Os(As)
desenvolvedores(as) do "Qt" sempre tem preferido fazer
lançamentos ao mesmo tempo que o resto do "Qt" (em vez de
adicionar correções de emergência), mas com versões estáveis
sendo lançadas depois da versão atual de desenvolvimento. Agora
que eles(as) desejam migrar para o "Qt6", os lançamentos 5.15.3 e
posteriores do "Qt-5.15" estão inicialmente disponíveis somente
para clientes pagantes. "QtWebEngine" é uma exceção por causa da
licença "LGPL" dele, mas levar os fontes "git" (com o submódulo
bifurcado do "Chromium") para uma posição onde eles sejam
construídos com sucesso em um sistema atual do BLFS pode exigir
muito esforço e, portanto, atualizações para o livro
possivelmente sejam atrasadas.
Parece provável que as futuras versões da série 5.15 também serão
lançadas muito depois das vulnerabilidades do "Chromium" serem
conhecidas, mas correções para o "QtWebEngine" podem ser
encontradas no "git" e os(as) editores(as) consideram que as
vulnerabilidades conhecidas nos navegadores deveriam ser
corrigidas.
O tarball vinculado abaixo foi criado a partir da ramificação
5.15.15 do git e da 87-branch do submódulo chromium (que é
bifurcada a partir do chromium). Veja-se o arquivo GIT-VERSIONS
no tarball para detalhes dos commits mais recentes.
Esse pacote é conhecido por construir e funcionar corretamente
usando uma plataforma LFS 12.0.
Atenção
Por padrão, o ninja usará todas as CPUs online mais duas (se
existirem pelo menos quatro), mesmo que elas não estejam
disponíveis para a tarefa atual porque o terminal de construção
tenha sido restringido com o 'taskset'. No BLFS, esse pacote leva
mais tempo para construir que qualquer outro. Em um exemplo, a
construção desse pacote travou no ponto de cerca de noventa por
cento (90%) devido a um problema de falta de memória em um
sistema com vinte e quatro (24) elementos de processamento e
trinta e dois (32) GB de memória.
Para contornar isso, vejam-se as Explicações do Comando abaixo.
Nota
Se estiver atualizando e tiver instalado uma versão mais recente
do "ICU-73.2" desde a última instalação do "Qt-5.15.10",
[então] você precisará reinstalar o "Qt5" antes de atualizar,
caso contrário, o link final desse pacote falhará com um aviso de
que a versão das bibliotecas "icu" necessárias para
"libQt5Core.so" possivelmente conflitem com a versão usada para
esse pacote.
Excepcionalmente, o sistema de construção "GN" fornecido (usado
para criar os arquivos "Ninja") exige uma "libstdc++.a
" estática, embora as bibliotecas
instaladas usem corretamente a versão compartilhada. Se essa
biblioteca estática não estiver presente, [então] a construção
falhará muito rapidamente. Por favor, observe que se você tentar
construir o "webengine" como parte do "Qt" e a biblioteca estática não estiver
disponível, [então] essa construção será, ou concluída sem
instalar o "webengine" ou, do contrário, falhará durante a
instalação (ambas as variantes foram observadas em 5.12 .0).
Informação do Pacote
Transferências Adicionais
Dependências do "qtwebengine"
Exigidas
nodejs-18.17.1, nss-3.92, pciutils-3.10.0 e (Qt-5.15.10 ou componentes-qt-5.15.10 com qtlocation
e qtwebchannel)
Recomendadas
Nota
Se esses pacotes não estiverem instalados, [então] o processo de
construção compilará e instalará a própria versão dele (talvez
mais antiga), com o efeito colateral de aumentar a construção e
espaço instalado em disco e o tempo de construção.
ou alsa-lib-1.2.9 ou PulseAudio-16.1 (ou ambos), FFmpeg-6.0,
ICU-73.2 (construído antes do libxml2-2.10.4) , libwebp-1.3.1,
libxslt-1.1.38 e Opus-1.3.1
Opcionais
libevent-2.1.12, MIT
Kerberos V5-1.21.2, pipewire-0.3.77, Poppler-23.08.0, jsoncpp,
libsrtp, snappy
Observações de Editor(a): https://wiki.linuxfromscratch.org/blfs/wiki/qtwebengine
Instalação do qtwebengine
Aplique um remendo para corrigir vários problemas que podem impedir
a construção de completar e para forçá-la a usar o "python3":
patch -Np1 -i ../qtwebengine-5.15.15-build_fixes-1.patch
Aplique um remendo que resolve problemas ao construir com ffmpeg-5
e posterior:
patch -Np1 -i ../qtwebengine-5.15.15-ffmpeg5_fixes-1.patch
Embora o remendo "build_fixes" tenha garantido que o "git" não seja
invocado durante a construção, o sistema de construção tem regras
labirínticas de complexidade bizantina e, em particular, tentar
construir sem dois diretórios ".git
"
o levará a eventualmente cair em código inesperado e não
construível que referencia um cabeçalho privado que não foi criado.
Evite isso criando os diretórios exigidos:
mkdir -pv .git src/3rdparty/chromium/.git
Como essa versão do "qtwebengine" se destina a um lançamento
posterior aos lançamentos públicos atuais, mude-a para construir
para "qt-5.15.10" usando um "sed":
sed -e '/^MODULE_VERSION/s/5.*/5.15.10/' -i .qmake.conf
Agora, certifique-se de que os cabeçalhos locais estejam
disponíveis quando não construir como parte do "Qt-5.15.10" completo:
find -type f -name "*.pr[io]" |
xargs sed -i -e 's|INCLUDEPATH += |&$$QTWEBENGINE_ROOT/include |'
Em seguida, permita que a biblioteca "pulseaudio" seja vinculada em
tempo de construção, em vez de em tempo de execução. Isso também
evita um problema com o "pulseaudio" mais recente:
sed -e '/link_pulseaudio/s/false/true/' \
-i src/3rdparty/chromium/media/media_options.gni
A seguir, corrija as ferramentas de construção, de forma que elas
possam ser executadas com "Python-3.11+":
sed -e 's/\^(?i)/(?i)^/' \
-i src/3rdparty/chromium/tools/metrics/ukm/ukm_model.py &&
sed -e "s/'rU'/'r'/" \
-i src/3rdparty/chromium/tools/grit/grit/util.py
Finalmente, corrija uma mudança no sistema de construção que
permite que os(as) desenvolvedores(as) dele passem, por exemplo,
"-j20" para o "make" (para testes rápidos de algumas áreas), mas
quebra a construção com o uso do LFS da variável de ambiente
"NINJAJOBS":
sed -i 's/NINJAJOBS/NINJA_JOBS/' src/core/gn_run.pro
Instale o "qtwebengine" executando
os seguintes comandos:
mkdir build &&
cd build &&
qmake .. -- -system-ffmpeg -proprietary-codecs -webengine-icu &&
make
Esse pacote não vem com uma suíte de teste.
Agora, como o(a) usuário(a) "root
":
make install
Remova referências ao diretório de construção dos arquivos
instalados de dependência de biblioteca ("prl") executando os
seguintes comandos como o(a) usuário(a) "root
":
find $QT5DIR/ -name \*.prl \
-exec sed -i -e '/^QMAKE_PRL_BUILD_DIR/d' {} \;
Explicações do Comando
qmake: Isso
construirá a cópia incluída do "ninja" se ele já não estiver instalado e a
usará para configurar a construção.
-- -system-ffmpeg -proprietary-codecs
-webengine-icu: Se quaisquer opções forem passadas
para o "qmake", [então] elas precisam vir depois de "--" que
precisa seguir ".." que aponta para o diretório principal. As
opções aqui fazem com que ele use o "ffmpeg" do sistema e o "icu"
do sistema. A opção "-proprietary-codecs" permite que o "ffmpeg"
decodifique os codificadores "H264" e "H265". Se construído como
parte do "Qt5" completo, [então] o "icu" do sistema será usado
automaticamente (somente) pelo "Qt5Core" se ele estiver disponível,
mas, a menos que essa opção seja usada, o "webengine" sempre usará
a cópia dele enviada do "icu", adicionando tempo e espaço à
construção.
-webengine-jumbo-build 0
: Se isso for
adicionado ao comando "qmake", [então] fará com que o "Jumbo Build
Merge Limit" seja informado como "no" em vez de oito (08). Isso
desliga a construção "jumbo". Algumas distribuições fazem isso para
obter uma construção menor em algumas arquiteturas como "MIPS". No
"x86_64" pode economizar um pouco de espaço na construção, mas o
tempo de construção aumentará muito.
-webengine-kerberos
: Adicione isso se
tiver instalado o "MIT Kerberos V5-1.21.2" e
desejar se conectar a partir de um navegador usando o "QtWebEngine"
a um servidor "web" que exija que você se conecte via "kerberos".
NINJAJOBS=4 make
: Se você remendou o
"ninja" do sistema no LFS para reconhecer a variável de ambiente
"NINJAJOBS," [então] esse comando executará o "ninja" do sistema
com o número especificado de tarefas (ou seja, quatro). Existem
várias razões pelas quais você poderia querer usar opções como
essa:
-
Construir em um subconjunto de "CPUs" permite medir o tempo
de construção para um número menor de processadores e (ou)
executar outras tarefas com uso intensivo da "CPU" ao mesmo
tempo. Para um(a) editor(a) em uma máquina com muitas "CPUs",
tentando medir o tempo de construção para uma máquina com
quatro "CPUs", "NINJAJOBS=4 make
"
fornecerá uma aproximação razoável (existe um curto período
onde N+2 tarefas "python" e "node" executam).
-
Em uma máquina com somente quatro "CPUs" "online", o padrão
de agendamento de tarefas N+2 para o "qtwebengine" é mais
lento entre três por cento (3%) e sete por cento (7%),
provavelmente devido ao tamanho dos arquivos" C++" e às
muitas inclusões e modelos deles. Portanto, se em dúvida,
[então] configure "NINJAJOBS" para o número de "CPUs".
-
Reduzindo o número de núcleos sendo usados em execução
prolongada, os pacotes com uso intensivo de "CPU"
possivelmente aliviem os problemas de aquecimento.
-
Reduzir o número de núcleos evitará potenciais problemas de
falta de memória em sistemas que não tenham memória
suficiente (ou troca) quando todos os núcleos estiverem
ativos. Uma abordagem sugerida é a de limitar o número de
núcleos a cerca de um núcleo para cada 1,5 GB de "RAM" e
espaço de troca combinados.
Configuração do Núcleo
Esse pacote não exige nenhum dos itens opcionais de espaço de nome
do núcleo, mas se o espaço de nome de Usuário(a) estiver habilitado
, (como acontece em alguns arquivos de
unidade, para proteção), [então] o espaço de nome de "PID"
também precisa ser habilitado. Nesse caso, habilite as seguintes
opções na configuração do núcleo e recompile o núcleo se
necessário:
General setup --->
-*- Namespaces support ---> [NAMESPACES]
# Enable or disable *both* of them:
[ /*] User namespace [USER_NS]
[ /*] PID Namespaces [PID_NS]