public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Uladzimir Bely <ubely@ilbers.de>
To: Jan Kiszka <jan.kiszka@siemens.com>,
	isar-users <isar-users@googlegroups.com>,
	"Moessbauer, Felix (T CED SES-DE)" <felix.moessbauer@siemens.com>,
	"Schmidt, Adriaan" <adriaan.schmidt@siemens.com>
Subject: Re: [PATCH v3] base: Fix HOST_ARCH for native builds
Date: Thu, 05 Oct 2023 13:17:56 +0300	[thread overview]
Message-ID: <ed706a8ff04b0dca355bb7ac12544bb9f3263b3a.camel@ilbers.de> (raw)
In-Reply-To: <b375e537-7df5-4d86-b094-6a3c3dc7a4bd@siemens.com>

On Thu, 2023-10-05 at 11:37 +0200, Jan Kiszka wrote:
> On 05.10.23 10:36, 'Jan Kiszka' via isar-users wrote:
> > On 05.10.23 08:56, 'Jan Kiszka' via isar-users wrote:
> > > On 05.10.23 07:48, Uladzimir Bely wrote:
> > > > On Sun, 2023-10-01 at 11:09 +0200, Jan Kiszka wrote:
> > > > > From: Jan Kiszka <jan.kiszka@siemens.com>
> > > > > 
> > > > > HOST_ARCH must be DISTRO_ARCH when we are not cross-building.
> > > > > Otherwise,
> > > > > recipes that set PACKAGE_ARCH to it will fail in native
> > > > > builds.
> > > > > 
> > > > > To avoid recursions, we have to rework the ISAR_CROSS_COMPILE
> > > > > setting
> > > > > in
> > > > > imagetypes.bbclass to an anonymous python function.
> > > > > 
> > > > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > > > > ---
> > > > > 
> > > > > This looks better now.
> > > > > 
> > > > > Maybe we can even kill BUILD_HOST_ARCH, now that HOST_ARCH is
> > > > > fixed.
> > > > > 
> > > > >  meta/classes/base.bbclass       | 6 ++++--
> > > > >  meta/classes/imagetypes.bbclass | 6 ++++--
> > > > >  2 files changed, 8 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/meta/classes/base.bbclass
> > > > > b/meta/classes/base.bbclass
> > > > > index 88004120..f315a9d5 100644
> > > > > --- a/meta/classes/base.bbclass
> > > > > +++ b/meta/classes/base.bbclass
> > > > > @@ -49,13 +49,15 @@ def oe_import(d):
> > > > >  # We need the oe module name space early (before INHERITs
> > > > > get added)
> > > > >  OE_IMPORTED := "${@oe_import(d)}"
> > > > >  
> > > > > -def get_deb_host_arch():
> > > > > +def get_deb_host_arch(d):
> > > > >      import subprocess
> > > > > +    if d.getVar("ISAR_CROSS_COMPILE") != "1":
> > > > > +        return d.getVar("DISTRO_ARCH")
> > > > >      host_arch = subprocess.check_output(
> > > > >          ["dpkg", "--print-architecture"]
> > > > >      ).decode('utf-8').strip()
> > > > >      return host_arch
> > > > > -HOST_ARCH ??= "${@get_deb_host_arch()}"
> > > > > +HOST_ARCH ??= "${@get_deb_host_arch(d)}"
> > > > >  HOST_DISTRO ??= "${DISTRO}"
> > > > >  
> > > > >  die() {
> > > > > diff --git a/meta/classes/imagetypes.bbclass
> > > > > b/meta/classes/imagetypes.bbclass
> > > > > index a3be0a1d..205377b1 100644
> > > > > --- a/meta/classes/imagetypes.bbclass
> > > > > +++ b/meta/classes/imagetypes.bbclass
> > > > > @@ -65,8 +65,10 @@ UBIFS_IMG ?=
> > > > > "${PP_DEPLOY}/${IMAGE_FULLNAME}.ubifs"
> > > > >  
> > > > >  # glibc bug 23960
> > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=23960
> > > > >  # should not use QEMU on armhf target with mkfs.ubifs <
> > > > > v2.1.3
> > > > > -THIS_ISAR_CROSS_COMPILE := "${ISAR_CROSS_COMPILE}"
> > > > > -ISAR_CROSS_COMPILE:armhf =
> > > > > "${@bb.utils.contains('IMAGE_BASETYPES',
> > > > > 'ubifs', '1', '${THIS_ISAR_CROSS_COMPILE}', d)}"
> > > > > +python() {
> > > > > +    if d.getVar('DISTRO_ARCH') == 'armhf' and
> > > > > bb.utils.contains('IMAGE_BASETYPES', 'ubifs', True, False,
> > > > > d):
> > > > > +        d.setVar('ISAR_CROSS_COMPILE', '1')
> > > > > +}
> > > > >  
> > > > >  IMAGE_CMD:ubifs() {
> > > > >      ${SUDO_CHROOT} /usr/sbin/mkfs.ubifs ${MKUBIFS_ARGS} \
> > > > 
> > > > The patch is merged now, but it seems to bring a regression.
> > > > 
> > > > Now, native compilation if imx6-sabrelite fails, because we set
> > > > ISAR_CROSS_COMPILE to "1", while it seems should be "0" (like
> > > > previously used temporary value of THIS_ISAR_CROSS_COMPILE.
> > > > 
> > > 
> > > No, this is correct: The image recipe must have
> > > ISAR_CROSS_COMPILE = "1"
> > > because of
> > > 
> > > # glibc bug 23960
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=23960
> > > # should not use QEMU on armhf target with mkfs.ubifs < v2.1.3
> > > 
> > > Package recipes have it disabled, as desired.
> > > 
> > 
> > ISAR_CROSS_COMPILE is indeed correct - but too late. The problem is
> > that
> > the crossvars does not see the python block results of imagetypes,
> > thus
> > switches to native build for the imager.
> > 
> > I'm playing with yet another variant that looks more like the
> > original
> > code but avoids the recursion-triggering override.
> > 
> 
> Nope, does not fly, we need to revert: It is glued into isar that
> HOST_ARCH is static and does not depend on ISAR_CROSS_COMPILE. Users
> of
> HOST_ARCH that expect such a dependency should have taken
> BUILD_HOST_ARCH. Now I see what we have two.
> 
> So the bugs are elsewhere in the code, e.g. in those recipes that do
> 
> PACKAGE_ARCH = "${HOST_ARCH}"
> 
> but probably also in sdk.bbclass, native.bbclass, multiarch.bbclass,
> essential.bbclass - if not more. Checking.
> 
> Sigh.
> 
> Jan
> 

One more a bit silly moment that HOST_ARCH in Isar has a different
meaning than in Yocto/OE.

Isar's HOST_ARCH = OE's BUILD_ARCH
Isar's DISTRO_ARCH = OE's HOST_ARCH

When we borrow some classes from OE, it may create problems (like in
topic https://groups.google.com/g/isar-users/c/2TNQPOb0IXY ).

  reply	other threads:[~2023-10-05 10:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-01  9:09 Jan Kiszka
2023-10-03 16:11 ` Uladzimir Bely
2023-10-05  5:48 ` Uladzimir Bely
2023-10-05  6:56   ` Jan Kiszka
2023-10-05  8:18     ` Uladzimir Bely
2023-10-05  8:36     ` Jan Kiszka
2023-10-05  9:37       ` Jan Kiszka
2023-10-05 10:17         ` Uladzimir Bely [this message]
2023-10-05 10:39           ` Jan Kiszka

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=ed706a8ff04b0dca355bb7ac12544bb9f3263b3a.camel@ilbers.de \
    --to=ubely@ilbers.de \
    --cc=adriaan.schmidt@siemens.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    /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