on dunfell, gdk-pixbuf fails to open its loader plugins: it uses buildhost paths (even recipe-sysroot-native ones) # pavucontrol (pavucontrol:1512): Gtk-WARNING **: 09:52:57.072: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg. This may indicate that pixbuf loaders or the mime database could not be found. ** Gtk:ERROR:../../gtk+-3.24.14/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unable to load image-loading module: /home/gitlab-runner/builds/[REDACTED]/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../../../usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so: /home/gitlab-runner/builds/[REDACTED]/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/../../../usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so: cannot open shared object file: No such file or directory (gdk-pixbuf-error-quark, 5)
This may be multilib-related: I see it on our x86-64 target, but not on our rk3399 one.
@yann Can you explain how to build the image for Matthew?
Yann, please provide the steps to reproduce the build.
AFAICT it's fixed in 3.1.2
Oh, not so in fact. The problem does not show on arm64 target, but it still does on x86-64.
Can you explain exactly which MACHINE and multilib configuration is being used when you see this issue?
After some digging and checking it does not happen with qemux86-64, I found out the faulty paths are in /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache, generated by the update_pixbuf_cache postinst-intercept. The exact target is amdfalconx86 (which used to be in meta-amd), which uses a cpu tuning not supported by qemu, and to allow generation of a squashfs image I had to adapt the intercepts... and something broke between sumo and dunfell. So that's clearly not an OE bug, closing.