Re: multilib: lib32-libgdiplus complaining about qemuwrapper
I am using Yocto 2.5 and have a working multilib-enabled image based on poky which includes libgdiplus (64-bit). Due to requirements I had to add the 32-bit version, so I added lib32-libgdiplus to my image recipe. This caused the following error output from bitbake:
WARNING: tmlinux-image-1.0-r0 do_rootfs: The postinstall intercept hook 'update_gio_module_cache-lib32' failed, details in /home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/temp/log.do_rootfs
While searching for the root cause of this, I discovered a change to update_gio_module_cache (https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/scripts/postinst-intercepts/update_gio_module_cache?id=87631af64032b18ea354b27cc586ec13391bd143) that I thought might help. I applied this change (and the changes from https://github.com/openembedded/openembedded-core/commit/d10fd6ae3fe46290c6e3a5250878966d9f12ca3f for the qemuwrapper-cross_1.0.bb recipe) to my local code, and once again tried building the image. The error message from bitbake is the same, but in the do_rootfs log I find this:
/home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/intercept_scripts-bd1c31820bf736a004f4ebe71461d6fa3ae23f7d97783c8f28a606e086741d8a/update_gio_module_cache-lib32: 15: /home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/intercept_scripts-bd1c31820bf736a004f4ebe71461d6fa3ae23f7d97783c8f28a606e086741d8a/update_gio_module_cache-lib32: lib32-qemuwrapper: not found
If I search my tmp directory, there is nothing called "lib32-qemuwrapper", but there is "lib32-qemuwrapper-cross".Hi again,
I have spent a few more hours digging into this and made some discoveries. The problem does not seem to be directly with libgdiplus, but with glib-2.0, which is responsible for calling the "update_gio_module_cache" script, which gets set up as a postinstall intercept script. The update_gio_module_cache script gets executed both for the regular libgdiplus (works fine), and for lib32-libgdiplus. The issue is with lib32-libgdiplus, because lib32-libgdiplus wants to run "lib32-qemuwrapper", but the location of lib32-qemuwrapper is not in the PATH when it runs the update_gio_module_cache-lib32 script (it seems like the incorrect sysroot is used).
When looking at the output from bitbake -e for my image recipe, I can see that the variable that points out the location for the recipe-sysroot ($STAGING_DIR_HOST) directory gets correctly set up for the non-lib32 packages, but it uses the same variable content when running update_gio_module_cache-lib32. It seems to me like the do_rootfs task would have to do a second pass, with the recipe-sysroot set up correctly for multilib packages, to get this working. I am not familiar enough with bitbake to understand exactly how this should be resolved. My current "solution" is to modify the package_manager.py script to manually add the lib32-sysroot to the path before running intercept scripts (really ugly). Any pointers in the right direction would be much appreciated.