diff mbox series

fsl-dynamic-packageearch.bbclass improvement for MULTILIB support

Message ID CO6P222MB0554CDF997D5CC8E742B82E09C419@CO6P222MB0554.NAMP222.PROD.OUTLOOK.COM
State New
Headers show
Series fsl-dynamic-packageearch.bbclass improvement for MULTILIB support | expand

Commit Message

Deroire, Guillaume Sept. 7, 2022, 4:22 p.m. UTC 
Hi,

I have recently tried to use the MULTILIB feature of Yocto Dunfell on a iMX8 platform and I was not able anymore to build the SDK as soon as I add the lib32-libusb1 in the package list.
Libusb1 has a dependency on wayland-protocols and it seems Yocto can find any suitable version of lib32-wayland-protocols during do_populate_sdk.

Here is the error I got:
> test-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: test-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/test-image/1.0-r0/temp/log.do_populate_sdk.2532219
> ERROR: Task (/workdir/oe-core/build/../layers/meta-eagle/recipes-images/images/test-image.bb:do_populate_sdk) failed with exit code '1'

However I can found "manifest-armv7at2hf-neon-mx8-lib32-wayland" in the sstate-control folder.

I'm a bit lost in that piece of code, but my understanding is that the fsl-dynamic-packagearch.bbclass is appending an additional ARCH based on the current ARCH + the "MACHINE_SOCARCH_SUFFIX" suffix, but doesn't manage the MULTILIB architectures.

I have draft a patch to manage all ARCH coming from MULTILIB that seems to fix the problem but I would appreciate any comments (is it the right way to fix the problem, is the patch correct ...)



Kind regards

Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

Comments

Otavio Salvador Sept. 7, 2022, 7:59 p.m. UTC | #1 
Em qua., 7 de set. de 2022 às 13:22, Deroire, Guillaume via
lists.yoctoproject.org <Guillaume.Deroire=hach.com@lists.yoctoproject.org>
escreveu:

> I have draft a patch to manage all ARCH coming from MULTILIB that seems to
> fix the problem but I would appreciate any comments (is it the right way to
> fix the problem, is the patch correct ...)
>

Could you prepare a PR against master (in github) and add a explanation how
to reproduce the error in commit log?
diff mbox series

Patch

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.