Thanks to your support, I’m able to run some application properly however I’m now facing a problem to generate a proper SDK as soon as I’m adding lib32-libusb1 package to the image.
I get the following error
WARNING: eagle-image-1.0-r0 do_populate_sdk: Manifest /workdir/oe-core/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-wayland-protocols.package_write_ipk not found in 1388_imx8x aarch64-mx8 armv7at2hf-neon armv7ahf-neon armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk (variant 'lib32')?
ERROR: eagle-image-1.0-r0 do_populate_sdk: No manifest generated from: lib32-wayland-protocols in virtual:multilib:lib32:/workdir/oe-core/build/../layers/meta-toradex-nxp/backports/recipes-graphics/wayland/wayland-protocols_1.20.imx.bb
ERROR: Logfile of failure stored in: /workdir/oe-core/build/tmp/work/1388_imx8x-tdx-linux/eagle-image/1.0-r0/temp/log.do_populate_sdk.2532219
ERROR: Task (/workdir/oe-core/build/../layers/meta-eagle/recipes-images/images/eagle-image.bb:do_populate_sdk) failed with exit code '1'
I can see that I have two manifests in the sstate-control folder:
but not the “probably” expected “manifest-armv7at2hf-neon-lib32-wayland-protocols.package_write_ipk”
My current understanding is that:
the first manifest is the one generated before I have added lib32-libusb1
the second manifest is the one generated with lib32-libusb1 (which has an indirect dependency on wayland-protocols)
For some reason, the ARCH used is “armv7at2hf-neon-mx8” whereas the do_populate_sdk task is looking for “armv7at2hf-neon”. My understanding is that “fsl-dynamic-packagearch.bbclass” appends the “aarch64-mx8” arch and should probably also append the “armv7at2hf-neon-mx8” arch in MULTILIB.
Are my assumptions correct and what could be the proper way to fix the problem and generates a SDK including lib32-libusb1 ?
I’m not sure to catch the whole picture of the internal behavior of the sdk generation, but I have drafted a patch to manage all ARCH coming from MULTILIB. It seems to fix the problem but I would appreciate any comments on it.
Is it the real origin of the problem, is it the right way to fix the problem, is the patch correct …
diff --git a/classes/fsl-dynamic-packagearch.bbclass b/classes/fsl-dynamic-packagearch.bbclass
index 9fcf37be..f8b12a2c 100644
--- a/classes/fsl-dynamic-packagearch.bbclass
+++ b/classes/fsl-dynamic-packagearch.bbclass
@@ -54,6 +54,17 @@ python __anonymous () {
if not machine_socarch in cur_package_archs:
d.appendVar("PACKAGE_EXTRA_ARCHS", " %s" % machine_socarch)
+ multilib_variants = (d.getVar("MULTILIB_VARIANTS") or "").split()
+ for variant in multilib_variants:
+ defaulttune = d.getVar("DEFAULTTUNE_virtclass-multilib-" + variant)
+ if defaulttune:
+ package_extra_archs_tune_archs = (d.getVar("PACKAGE_EXTRA_ARCHS_tune-" + defaulttune) or "").split()
+ arch_suffix = d.getVar("MACHINE_SOCARCH_SUFFIX")
+ for arch in package_extra_archs_tune_archs:
+ socarch = arch + arch_suffix
+ if not socarch in cur_package_archs:
+ d.appendVar("PACKAGE_EXTRA_ARCHS", " %s" % socarch )
+
if d.getVar("TUNE_ARCH") == "arm":
# For ARM we have two possible machine_socarch values, one for the arm and one for the thumb instruction set
# add the other value to extra archs also, so that a image recipe searches both for packages.
I’ve been trying to reproduce the same error you faced with the lib32-libusb1 while doing the multilib build. I’ve indeed been able to reproduce the same error with wayland-protocols generating a wrong folder name that was not able to populate the SDK.
Yocto could build lib32-wayland-protocols alone but once I tried to make lib32-libusb1 together with it crashed and I couldn’t find one other solution for this.
Therefore, if your patch is able to mitigate this issue and you can run your application as desired without any major drawbacks I’d suggest you continue using your patch and tag your answer as the solution. If we do find in the future one alternative for this, we’ll update the post.
