meta-freescale.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: "Deroire, Guillaume" <Guillaume.Deroire@hach.com>
To: "meta-freescale@lists.yoctoproject.org"
	<meta-freescale@lists.yoctoproject.org>
Subject: fsl-dynamic-packageearch.bbclass improvement for MULTILIB support
Date: Wed, 7 Sep 2022 16:22:17 +0000	[thread overview]
Message-ID: <CO6P222MB0554CDF997D5CC8E742B82E09C419@CO6P222MB0554.NAMP222.PROD.OUTLOOK.COM> (raw)

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 ...)

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.


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.


             reply	other threads:[~2022-09-07 16:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07 16:22 Deroire, Guillaume [this message]
2022-09-07 19:59 ` [meta-freescale] fsl-dynamic-packageearch.bbclass improvement for MULTILIB support Otavio Salvador

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO6P222MB0554CDF997D5CC8E742B82E09C419@CO6P222MB0554.NAMP222.PROD.OUTLOOK.COM \
    --to=guillaume.deroire@hach.com \
    --cc=meta-freescale@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).