13963 2020-06-29 02:57:08 +0000 gdk-pixbuf looks for loaders in build dir 2020-09-10 11:13:20 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other unspecified x86 Multiple RESOLVED INVALID Medium+ normal 3.2 M3 1 ydirson ydirson randy.macleod ross.burton --- --- No (bug/feature does not impact docs) oldest_to_newest 87658 0 ydirson 2020-06-29 02:57:08 +0000 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) 87694 1 ydirson 2020-07-06 01:56:46 +0000 This may be multilib-related: I see it on our x86-64 target, but not on our rk3399 one. 87721 2 randy.macleod 2020-07-09 07:36:34 +0000 @yann Can you explain how to build the image for Matthew? 87998 3 randy.macleod 2020-08-20 09:22:10 +0000 Yann, please provide the steps to reproduce the build. 88116 4 ydirson 2020-09-07 02:30:50 +0000 AFAICT it's fixed in 3.1.2 88117 5 ydirson 2020-09-07 04:14:04 +0000 Oh, not so in fact. The problem does not show on arm64 target, but it still does on x86-64. 88131 6 randy.macleod 2020-09-10 08:18:57 +0000 Can you explain exactly which MACHINE and multilib configuration is being used when you see this issue? 88134 7 ydirson 2020-09-10 11:13:20 +0000 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.