From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7280073785777061888 X-Received: by 2002:a17:906:cb:b0:9ae:4eb7:ae8b with SMTP id 11-20020a17090600cb00b009ae4eb7ae8bmr4977223eji.7.1696501079301; Thu, 05 Oct 2023 03:17:59 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:4442:0:b0:31f:edbf:7fa with SMTP id x2-20020a5d4442000000b0031fedbf07fals355600wrr.2.-pod-prod-05-eu; Thu, 05 Oct 2023 03:17:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE8g8zIAC2nIyH9MwZ9UtZMh2/s07U05mKRbapweLd8w0mQwcCjsorP+6x32ZEZfd83FL4E X-Received: by 2002:adf:e541:0:b0:317:69d2:35be with SMTP id z1-20020adfe541000000b0031769d235bemr4513945wrm.30.1696501077190; Thu, 05 Oct 2023 03:17:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696501077; cv=none; d=google.com; s=arc-20160816; b=kSj3mEX5d+MFGv+MnJS+GKuPkcafbLDe2UXeIO0DNOUqUo+axMAfXlTt2TtfMobRZi LuWN9Sd/fitRPn4u+GVYdm/dvSyaXzc8eNK7wsN/I19oToYsVpezpMS8Fe832e5UaLAS q1sheYX3RjwjyTRu1lorbIqQ2hEmL38Gtn/x58AJ00Bw0dEhtJwhYzK4NkVKQc0QSwvD Pf6rtHl/PsTAM0SMJ0Tjr7nV+e23uYMcE4CWT3Jr+qpFxHC/oRcD7gtDmRLhYZeak7lQ Jp8m//I/RMIPQ1fHnz2WvDQxvxaQxhl4vcoT4NpWpvQtraClH994djgxS9w4V312nHBk roJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id; bh=gTFW9Gf5zfnDPWRTMY6ewkoU4Z1mhFIzvcK+NEL4CpA=; fh=7aPAWF6RWzwB3KMAx5shEtAg7NGhFBliq4HtasVMFds=; b=grEpI7iF2x8Fu0k2p+5tq8G6qpGWWyCpDdtxt8wk7Iz0z0juz7ErAtgL8lqClgmAuZ TBG2w/T6NC2UF0/6IKxVmaUPm/fZ+9QiF+C/kxoj3ee+8hrY/S1eRmqTagq+tLlpelSG ie9erjApFmUvstILAXlJFqqFYEg/eIrsO8+FLwLFzT65tgXeEd1wMv/SWOcaUaHuSOL6 5xeL2NrrF1qe05SkdqiOI86AT8p4hoVpmclsZ9g937vNa6j/M7UwDXn3jT+qf0fdljFu d5HFywwNkKLaR52qvDLVZfPryKgimzMzcFYbTX7mkwCUtOt2CiSViHswqptABhOXIPu5 MsXQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id bt16-20020a056000081000b0031fe51902bdsi68273wrb.0.2023.10.05.03.17.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 05 Oct 2023 03:17:57 -0700 (PDT) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from [IPv6:::1] (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 395AHtcW027722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Oct 2023 12:17:56 +0200 Message-ID: Subject: Re: [PATCH v3] base: Fix HOST_ARCH for native builds From: Uladzimir Bely To: Jan Kiszka , isar-users , "Moessbauer, Felix (T CED SES-DE)" , "Schmidt, Adriaan" Date: Thu, 05 Oct 2023 13:17:56 +0300 In-Reply-To: References: <7e817969-de10-43fa-911d-639aa91e9499@siemens.com> <9c2cf410f9a3f13bd0d8c0091888fb1d29071c32.camel@ilbers.de> <0c292419-da7d-43ab-af00-c33322087130@siemens.com> <6ccb8acb-2fb8-41b7-be1c-f71fab948522@siemens.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (by Flathub.org) MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: O/OwyfPD4r5D 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 > > > > >=20 > > > > > 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. > > > > >=20 > > > > > To avoid recursions, we have to rework the ISAR_CROSS_COMPILE > > > > > setting > > > > > in > > > > > imagetypes.bbclass to an anonymous python function. > > > > >=20 > > > > > Signed-off-by: Jan Kiszka > > > > > --- > > > > >=20 > > > > > This looks better now. > > > > >=20 > > > > > Maybe we can even kill BUILD_HOST_ARCH, now that HOST_ARCH is > > > > > fixed. > > > > >=20 > > > > > =C2=A0meta/classes/base.bbclass=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | 6 ++++-- > > > > > =C2=A0meta/classes/imagetypes.bbclass | 6 ++++-- > > > > > =C2=A02 files changed, 8 insertions(+), 4 deletions(-) > > > > >=20 > > > > > 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): > > > > > =C2=A0# We need the oe module name space early (before INHERITs > > > > > get added) > > > > > =C2=A0OE_IMPORTED :=3D "${@oe_import(d)}" > > > > > =C2=A0 > > > > > -def get_deb_host_arch(): > > > > > +def get_deb_host_arch(d): > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 import subprocess > > > > > +=C2=A0=C2=A0=C2=A0 if d.getVar("ISAR_CROSS_COMPILE") !=3D "1": > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return d.getVar("DIST= RO_ARCH") > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 host_arch =3D subprocess.check_output( > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ["dpkg", "--prin= t-architecture"] > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 ).decode('utf-8').strip() > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 return host_arch > > > > > -HOST_ARCH ??=3D "${@get_deb_host_arch()}" > > > > > +HOST_ARCH ??=3D "${@get_deb_host_arch(d)}" > > > > > =C2=A0HOST_DISTRO ??=3D "${DISTRO}" > > > > > =C2=A0 > > > > > =C2=A0die() { > > > > > 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 ?=3D > > > > > "${PP_DEPLOY}/${IMAGE_FULLNAME}.ubifs" > > > > > =C2=A0 > > > > > =C2=A0# glibc bug 23960 > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 > > > > > =C2=A0# should not use QEMU on armhf target with mkfs.ubifs < > > > > > v2.1.3 > > > > > -THIS_ISAR_CROSS_COMPILE :=3D "${ISAR_CROSS_COMPILE}" > > > > > -ISAR_CROSS_COMPILE:armhf =3D > > > > > "${@bb.utils.contains('IMAGE_BASETYPES', > > > > > 'ubifs', '1', '${THIS_ISAR_CROSS_COMPILE}', d)}" > > > > > +python() { > > > > > +=C2=A0=C2=A0=C2=A0 if d.getVar('DISTRO_ARCH') =3D=3D 'armhf' and > > > > > bb.utils.contains('IMAGE_BASETYPES', 'ubifs', True, False, > > > > > d): > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 d.setVar('ISAR_CROSS_= COMPILE', '1') > > > > > +} > > > > > =C2=A0 > > > > > =C2=A0IMAGE_CMD:ubifs() { > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 ${SUDO_CHROOT} /usr/sbin/mkfs.ubifs ${MK= UBIFS_ARGS} \ > > > >=20 > > > > The patch is merged now, but it seems to bring a regression. > > > >=20 > > > > 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. > > > >=20 > > >=20 > > > No, this is correct: The image recipe must have > > > ISAR_CROSS_COMPILE =3D "1" > > > because of > > >=20 > > > # glibc bug 23960 > > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 > > > # should not use QEMU on armhf target with mkfs.ubifs < v2.1.3 > > >=20 > > > Package recipes have it disabled, as desired. > > >=20 > >=20 > > 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. > >=20 > > I'm playing with yet another variant that looks more like the > > original > > code but avoids the recursion-triggering override. > >=20 >=20 > 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. >=20 > So the bugs are elsewhere in the code, e.g. in those recipes that do >=20 > PACKAGE_ARCH =3D "${HOST_ARCH}" >=20 > but probably also in sdk.bbclass, native.bbclass, multiarch.bbclass, > essential.bbclass - if not more. Checking. >=20 > Sigh. >=20 > Jan >=20 One more a bit silly moment that HOST_ARCH in Isar has a different meaning than in Yocto/OE. Isar's HOST_ARCH =3D OE's BUILD_ARCH Isar's DISTRO_ARCH =3D 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 ).