nerves-project/nerves_system_br

QT5Webengine build fails with freetype2.pc error due to buildroot problem

wzin opened this issue · 2 comments

wzin commented

Environment

  • Elixir version (elixir -v): between 1.10 and 1.12.0
  • Nerves environment: (mix nerves.env --info)
  Pkg:         nerves_system_br
  Vsn:         1.17.4 (tested on all versions from 1.16.5 to 1.17.4)
  Type:        system_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_ctng
  Vsn:         1.7.2
  Type:        toolchain_platform
  BuildRunner: {nil, []}

  Pkg:         nerves_toolchain_x86_64_unknown_linux_gnu
  Vsn:         1.3.2 (tested on 1.4.3 and 1.5.0 as well)
  Type:        toolchain
  BuildRunner: {Nerves.Artifact.BuildRunners.Local, []}

nerves_defconfig file attached (.txt added for github):

nerves_defconfig.txt

NOTE: it's a rich system with many packages amongst which the BR2_QT5* packages are most important and related to this problem.

NOTE2: as this is related to buildroot, related bug was created here: https://bugs.busybox.net/show_bug.cgi?id=14461 and a discussion with @fhunleth followed here https://elixir-lang.slack.com/archives/C0AB4A879/p1639675372364800 :

Related buildroot bugs are located here:

and proposed fix will be mentioned later.

Current behavior

when buildroot's BR2_PACKAGE_QT5WEBENGINE flag is turned on the build will always fail with

ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned non-zero exit code.
    pkgresult = exec_script(pkg_config_script, args, "value")
                ^----------
Current dir: /common_cache/nerves/artifacts/rzjb_system_dev-portable-1.1.0/build/qt5webengine-5.15.2/src/core/release/
Command: /common_cache/nerves/artifacts/rzjb_system_dev-portable-1.1.0/host/bin/python2 /common_cache/nerves/artifacts/rzjb_system_dev-portable-1.1.0/build/qt5webengine-5.15.2/src/3rdparty/chromium/build/config/linux/pkg-config.py -p /common_cache/nerves/artifacts/rzjb_system_dev-portable-1.1.0/build/qt5webengine-5.15.2/host-bin/host-pkg-config freetype2
Returned 1.
stderr:
Package freetype2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype2.pc'
to the PKG_CONFIG_PATH environment variable
Package 'freetype2', required by 'virtual:world', not found
Could not run pkg-config.
See //build/linux/BUILD.gn:24:3: whence it was called.
  pkg_config("freetype_from_pkgconfig") {
  ^--------------------------------------
See //build/config/freetype/BUILD.gn:10:24: which caused the file to be included.
    public_configs = [ "//build/linux:freetype_from_pkgconfig" ]
                       ^--------------------------------------
Project ERROR: GN run error!
make[4]: *** [Makefile:82: sub-gn_run-pro-make_first] Error 3
make[3]: *** [Makefile:79: sub-core-make_first] Error 2
make[2]: *** [Makefile:49: sub-src-make_first] Error 2
make[1]: *** [package/pkg-generic.mk:270: /common_cache/nerves/artifacts/rzjb_system_dev-portable-1.1.0/build/qt5webengine-5.15.2/.stamp_built] Error 2
make: *** [Makefile:23: _all] Error 2

Expected behavior

Build does not error out.

Proposed change

It looks like qt5's webengine depends on FONTCONFIG https://github.com/buildroot/buildroot/blob/55a7666834e50cb756d7db2fb2ce7a535af61a77/package/qt5/qt5webengine/Config.in#L50 which depends on FREETYPE https://github.com/buildroot/buildroot/blob/55a7666834e50cb756d7db2fb2ce7a535af61a77/package/fontconfig/Config.in#L3. When chromium GNI scripts detect FREETYPE, they automatically set the use_system_freetype to true and use_bundled_fontconfig to false. Due some unknown reason, the pkg-config script ran during the build does not recognize the freetype2.pc installed in the sysroot of the target artifact. Adding host-freetype package to the buildroot fixes the problem because pkg-config now recognizes the freetype2.pc file in the host system.

Also big kudos to Peter Seiderer https://github.com/pseiderer for submitting the patch on this one https://patchwork.ozlabs.org/project/buildroot/patch/20201221203952.22168-3-ps.report@gmx.net/

fhunleth commented

@wzin This can be closed now, right?

wzin commented

hey @fhunleth yes - I'm closing it now.