Introduction to QtWebEngine
        
        
          QtWebEngine integrates
          chromium's web capabilities into
          Qt. It ships with its own copy of ninja which it uses for the build
          if it cannot find a system copy, and various copies of libraries
          from ffmpeg, icu, libvpx, and zlib (including libminizip) which
          have been forked by the chromium
          developers.
        
        
          This package is known to build and work properly using an LFS-10.1
          platform.
        
        
          ![[Note]](../images/note.png) 
          
            Note
          
          
            By default, ninja will use all online CPUs +2 (if at least 4
            exist), even if they are not available to the current task
            because the build terminal has been restricted with 'taskset'. To
            work around this, see the Command Explanations below.
          
          
            Unusually, the shipped GN build system (used to create the Ninja
            files) requires a static libstdc++.a although the installed libraries
            correctly use the shared version. If that static library is not
            present, the build will fail quite quickly. Please note that if
            you try to build webengine as part of Qt and the static library is not available,
            that build will either complete without installing webengine, or
            else fail during the install (both variants have been observed in
            5.12.0).
          
         
        
          Package Information
        
        
        
          Additional Downloads
        
        
        
          qtwebengine Dependencies
        
        
          Required
        
        
          NSS-3.61, Python-2.7.18,
          and Qt-5.15.2
        
        
          Recommended
        
        
          ![[Note]](../images/note.png) 
          
            Note
          
          
            If these packages are not installed, the build process will
            compile and install its own (perhaps older) version, with the
            side effect of increasing build and installed disk space and
            build time.
          
         
        
          either alsa-lib-1.2.4 or PulseAudio-14.2 (or both), FFmpeg-4.3.2, ICU-68.2, libwebp-1.2.0, libxslt-1.1.34, and Opus-1.3.1
        
        
          Optional
        
        
          libevent-2.1.12, Poppler-21.02.0, jsoncpp,
          libsrtp, snappy
        
        
          User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/qtwebengine
        
       
      
        
          Installation of qtwebengine
        
        
          First, ensure that the local headers are available when not
          building as part of the complete Qt-5.15.2:
        
        
find -type f -name "*.pr[io]" |
  xargs sed -i -e 's|INCLUDEPATH += |&$$QTWEBENGINE_ROOT/include |'
        
          Next, apply a patch that fixes the build with system ICU version
          68.1.
        
        
patch -Np1 -i ../qtwebengine-everywhere-src-5.15.2-ICU68-2.patch
        
          Now apply a patch to fix an issue introduced by glibc-2.33.
        
        
patch -Np1 -i ../qtwebengine-everywhere-src-5.15.2-glibc233-1.patch
        
          Next, allow the pulseaudio library to be linked at build time,
          instead of run time. This also prevents an issue with newer
          pulseaudio:
        
        
sed -e '/link_pulseaudio/s/false/true/' \
    -i src/3rdparty/chromium/media/media_options.gni
        
          Finally, fix a change in the build system which allows its
          developers to pass e.g. -j20 to make (for quick tests of some
          areas) but breaks the build with LFS's use of the NINJAJOBS
          environment variable:
        
        
sed -i 's/NINJAJOBS/NINJA_JOBS/' src/core/gn_run.pro
        
          If an older version of the package's main library has been
          installed, when the package is built separately it will link to
          that in preference to its own not-yet-installed version, and fail
          because of missing symbols. Prevent that by, as the root user, moving the symlink out of the way:
        
        
if [ -e ${QT5DIR}/lib/libQt5WebEngineCore.so ]; then
  mv -v ${QT5DIR}/lib/libQt5WebEngineCore.so{,.old}
fi
        
          Install qtwebengine by running the
          following commands:
        
        
mkdir build &&
cd    build &&
qmake .. -- -system-ffmpeg -webengine-icu &&
make
        
          This package does not come with a test suite.
        
        
          Now, as the root user:
        
        
make install
        
          Remove references to the build directory from installed library
          dependency (prl) files by running the following commands as the
          root user:
        
        
find $QT5DIR/ -name \*.prl \
   -exec sed -i -e '/^QMAKE_PRL_BUILD_DIR/d' {} \;
       
      
        
          Command Explanations
        
        
          qmake: This will
          build the included copy of ninja
          if it is not already installed and use it to configure the build.
        
        
          -- -system-ffmpeg
          -webengine-icu: If any options are passed to qmake
          they must come after '--' which must follow '..' that points to the
          main directory. The options here cause it to use system ffmpeg and
          system icu. If built as part of full Qt5, the system icu is
          automatically used (only) by Qt5Core if it is available, but unless
          this option is used webengine will always use its shipped copy of
          icu, adding time and space to the build.
        
        
          NINJAJOBS=4 make: If you patched system
          ninja in LFS to recognize the NINJAJOBS environment variable, this
          command will run system ninja with the specified number of jobs
          (i.e. 4). There are several reasons why you might want to do this:
        
        
          
            - 
              
                Building on a subset of CPUs allows measuring the build time
                for that number of processors or to run other CPU-intensive
                tasks on other cores.
               
- 
              
                Improving the build speed on a less-well endowed 4-core
                machine. On a machine with a powerful CPU and plenty of RAM,
                running N+2 jobs (the ninja default for 4+ cores) for the
                large working sets of the C++ compiles in this package is
                typically only marginally faster than running N jobs at a
                time. But for a machine with less memory it can be much
                slower.
               
- 
              
                Reducing the number of cores being used on long running, CPU
                intensive packages may alleviate heat problems.