Bug 13963

Summary:	gdk-pixbuf looks for loaders in build dir
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Yann Dirson <ydirson>
Component:	oe-core other	Assignee:	Yann Dirson <ydirson>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Medium+	CC:	randy.macleod, ross.burton
Version:	unspecified
Target Milestone:	3.2 M3
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Yann Dirson 2020-06-29 02:57:08 UTC

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)

Comment 1 Yann Dirson 2020-07-06 01:56:46 UTC

This may be multilib-related: I see it on our x86-64 target, but not on our rk3399 one.

Comment 2 Randy MacLeod 2020-07-09 07:36:34 UTC

@yann Can you explain how to build the image for Matthew?

Comment 3 Randy MacLeod 2020-08-20 09:22:10 UTC

Yann, please provide the steps to reproduce the build.

Comment 4 Yann Dirson 2020-09-07 02:30:50 UTC

AFAICT it's fixed in 3.1.2

Comment 5 Yann Dirson 2020-09-07 04:14:04 UTC

Oh, not so in fact.  The problem does not show on arm64 target, but it still does on x86-64.

Comment 6 Randy MacLeod 2020-09-10 08:18:57 UTC

Can you explain exactly which MACHINE and multilib configuration is being used when you see this issue?

Comment 7 Yann Dirson 2020-09-10 11:13:20 UTC

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.