Bug 13222

Yes if your splash image isn't a pre-generated .h then you need to add gdk-pixbuf-native as a build dependency.  We should document this.

Looking at poky/meta/recipes-core/psplash/psplash_git.bb line ~43 (haspng = True), it's already taken care of. Is that not enough? When you say `build dependency` you mean a Yocto one or an apt-install on the build machine?

So that *should* work.  Can you debug?

Well I think it's pretty weird that : 

ldd MY_BUILD_DIR/tmp/sysroots-components/x86_64/gdk-pixbuf-native/usr/bin/gdk-pixbuf-csource.real
	linux-vdso.so.1 (0x00007ffc43bf8000)
	libgdk_pixbuf-2.0.so.0 => MY_BUILD_DIR/tmp/sysroots-components/x86_64/gdk-pixbuf-native/usr/bin/../lib/libgdk_pixbuf-2.0.so.0 (0x00007f4b57c2b000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f4b57a27000)
	libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f4b57691000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f4b5743e000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f4b5712a000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f4b56ef7000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4b56cdd000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4b569d9000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4b567bc000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b5641d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4b56219000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f4b55ff1000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f4b55dda000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007f4b55b8c000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f4b55983000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f4b55710000)
	MY_BUILD_DIR/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f4b58054000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f4b554ca000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4b552c2000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f4b550bd000)


I would like to know why that binary `gdk-pixbuf-csource.real` is dynamically link to my own rootfs, mostly...?

It seems that the `subprocess.call` doesn't respect the yocto shell environment?

As you're not running that ldd from inside a devshell and on binaries in a constructed sysroot the ldd output will be wrong.

I would like to run the run.do_compile file but it's a python function and no environment.

How yocto handles the environment when replacing the do_* functions with python ones? Looking at the file (run.do_compile) there no environment variable set.

Once this defect is resolved, consider adding a brief note to the docs so that others know that having to manually compile the -native package is required when generating the image.

I would like to reiteration that it has nothing to do with the -native package (in a way).

I had to manually install, on my desktop computer at work, `sudo apt-get install libgtk2.0-0`, source the bitbake environement and then start the bitbake build to get it working.

I proceeded to purge `libgtk2.0-0` from my system, cleaned by yocto build directory, then restarted the bitbake build resulting in a failure.

No one has to build the -native package manually, there is a bug somewhere...

Can't replicate this with master.  My host machine has no libgtk installed, I added a png to SPLASH_IMAGES and it was converted successfully.