Re: multilib: lib32-libgdiplus complaining about qemuwrapper

Pelle Windestam

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
ERROR: tmlinux-image-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['100-lib32-libglib-2.0-0']
ERROR: tmlinux-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored 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.30106
ERROR: Task (/home/pelle/development/var-fsl-yocto/sources/meta-tagmaster/recipes-core/images/ failed with exit code '1'
While searching for the root cause of this, I discovered a change to update_gio_module_cache ( that I thought might help. I applied this change (and the changes from for the 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 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.


Join to automatically receive all group messages.