Re: [PATCH v3] base: Fix HOST_ARCH for native builds

[Jan Kiszka <jan.kiszka@siemens.com>]

On 05.10.23 12:17, Uladzimir Bely wrote:
> 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 ).

Yeah, saw this. This is messy but it is hard to change, even more when
HOST_ARCH would not just be renamed but semantically inverted.

Jan

-- 
Siemens AG, Technology
Linux Expert Center