[gtk+3][zeus] building only with wayland backend, no x11
|
Adrian
Hi, I am building an image based on core-image-weston. I would like to use only wayland backend, thus I defined in my machine's configuration:
I have a problem with build of gtk+3:
The configuration flags in config.log seems to be ok: $ ../gtk+-3.24.8/configure --build=x86_64-linux
--host=aarch64-poky-linux --target=aarch64-poky-linux
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share
--sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var
--libdir=/usr/lib --includedir=/usr/include
--oldincludedir=/usr/include --infodir=/usr/share/info
--mandir=/usr/share/man --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/home/afiergol/fastree/falcon/poky/build/tmp/work/aarch64-poky-linux/gtk+3/3.24.8-r0/recipe-sysroot
--enable-introspection --disable-gtk-doc --disable-glibtest
--disable-xinerama --enable-modules --disable-colord
--disable-gtk-doc --disable-static --disable-cups --disable-glx
--enable-opengl --enable-wayland-backend --disable-x11-backend
--enable-nls Has anybody else experience similar issue? Do you know a fix? I work with the latest zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) version. Regards, Adrian
|
|
|
|
Alexander Kanavin
Do you actually need gtk+3 in your image? There is a poky configuration that builds core-image-weston without x11, and core-image-weston does pull in gtk+3, and all that happens without errors: so I'd suggest you reproduce that, get it to build, then investigate where your build diverges. Alex On Mon, 9 Nov 2020 at 14:10, Adrian <adrian.fiergolski@...> wrote:
|
|
|
|
Adrian
Hi Alex, Thank you for the hint. It led me to the source of the problem, which was libepoxy. It looks that after changing configuration (DISTRO_FEATURES_remove = " x11"), SSTATE was still populating sysroot of gtk+3 with the older version of libepoxy configuration file (*.pc) creating dependency to 'gl' and 'x11'. In my case I had to call:
In order to avoid such issues in the future, is there any way to
force bitbake (after such considerable configuration change like
modification of DISTRO_FEATURES) to rebuild sysroot for each
recipe if necessary instead of grabbing them from the cache ? I
know, one could delete sstate-cache directory, but obviously it
will enormously increase rebuild time. I have been wondering
whether there is an intermediate solution. Regards, Adrian On 09.11.2020 15:28, Alexander Kanavin wrote:
|
|
|
|
Alexander Kanavin
This seems like libepoxy was not properly rebuilt when you changed DISTRO_FEATURS, even though it should have been. Can you try to reproduce the issue on master please? Alex On Tue, 10 Nov 2020 at 16:14, Adrian Fiergolski <adrian.fiergolski@...> wrote:
|
|
|