13222 2019-03-11 17:56:05 +0000 Host dependencies needed to rebuild psplash pngs 2021-11-11 12:31:13 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.7 x86 Multiple RESOLVED OBSOLETE Medium normal 4.0 1 maxime.roussinbelanger ross.burton meta.mr.watcher meta.watcher randy.macleod --- --- Don't know oldest_to_newest 83254 0 maxime.roussinbelanger 2019-03-11 17:56:05 +0000 We saw multiple builds fails after we removed a useless dependency, libgtk2.0-0, because it's not mentioned in the required packages for the build host. I think this is a bug, I don't think we should need to install libgtk2.0-0 to build...It should use the one in yocto, right? When trying to build our splash with a png image. We were greeted with this message: Error calling convert script '...../psplash/0.1+gitAUTOINC+2015f7073e-r15/git/make-image-header.sh' After I added some debugging information I got : failed to load "..../psplash/0.1+gitAUTOINC+2015f7073e-r15/ourlogo.png": Couldn\'t recognize the image file format for file \'..../psplash/0.1+gitAUTOINC+2015f7073e-r15/ourlogo.png\' When I restore libgtk2.0-0 with apt install, everything works. 83255 1 ross.burton 2019-03-11 18:03:57 +0000 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. 83256 2 maxime.roussinbelanger 2019-03-11 18:20:50 +0000 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? 83257 3 ross.burton 2019-03-11 19:55:01 +0000 So that *should* work. Can you debug? 83258 4 maxime.roussinbelanger 2019-03-11 20:41:07 +0000 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? 83259 5 ross.burton 2019-03-11 22:52:32 +0000 As you're not running that ldd from inside a devshell and on binaries in a constructed sysroot the ldd output will be wrong. 83260 6 maxime.roussinbelanger 2019-03-11 23:03:24 +0000 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. 83267 7 randy.macleod 2019-03-14 14:47:32 +0000 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. 83270 8 maxime.roussinbelanger 2019-03-14 20:01:49 +0000 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... 91951 9 ross.burton 2021-11-11 12:31:13 +0000 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.