public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "cedric.hombourger@siemens.com" <cedric.hombourger@siemens.com>,
	"Schmidt, Adriaan" <adriaan.schmidt@siemens.com>,
	"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Re: -native working as designed? target vs host sbuild-chroot
Date: Fri, 6 Oct 2023 07:27:23 +0200	[thread overview]
Message-ID: <fac2432e-e03b-4b61-854c-b81b66f1bcd9@siemens.com> (raw)
In-Reply-To: <eb2fb0fc-3ba1-4ca8-b92e-beb4a8a85360@siemens.com>

On 06.10.23 07:03, 'cedric.hombourger@siemens.com' via isar-users wrote:
> On 06/10/2023 06:59, Schmidt, Adriaan (T CED SES-DE) wrote:
>> cedric.hombourger@siemens.com, Friday, October 6, 2023 4:50 AM:
>>> Hello,
>>>
>>> I was wondering if handling of -native was working as designed (or if I
>>> am missing something).
>>>
>>> Let's consider the following steps:
>>>
>>>       git clone -b next https://github.com/ilbers/isar
>>>       . isar-init-build-env
>>>       mc:qemuarm64-bookworm:hello-native
>>>
>>> Observe that the build constructs sbuild-chroot-target when I would have
>>> expected sbuild-chroot-host. The sbuild environment for hello is indeed
>>> configured to build an amd64 package while running on an arm64 userland
>>> => the build of that package alone takes several minutes (on an Intel
>>> Xeon 6242 and with /proc/cpuinfo listing 64 processors)
>>>
>>> In addition, when using Isar from master (where support for -native and
>>> -compat is already there), the build fails to install build dependencies
>>> for hello-native:
>>>
>>> |  sbuild-build-depends-main-dummy:amd64 : Depends: libc-dev:amd64 but
>>> it is not installable
>>> |                                          Depends: libstdc++-dev:amd64
>>> but it is not installable
>>>
>>> This issue may also be reproduced on next with
>>> 7bc68bb27f562257977bb5f701564ab08d4c5b3a (base: Fix HOST_ARCH for native
>>> builds) removed. I guess I just making a note that -native may have
>>> issues on master.
>>>
>>> My outstanding question would be: shouldn't -native use the *host*
>>> sbuild-chroot? If we agree that it should then I am happy to look into this.
>> Hi Cedric,
>>
>> Yes, you are right. The problem seems to be that when building -native,
>> native.bbclass adapts PACKAGE_ARCH, but the selection of the sbuild-chroot
>> (via SCHROOT_DEP in crossvars.bbclass) selects based on DISTRO_ARCH.
>>
>> Can you try what happens with:
>>
>> diff --git a/meta/classes/crossvars.bbclass b/meta/classes/crossvars.bbclass
>> index df26f47f..508ba72d 100644
>> --- a/meta/classes/crossvars.bbclass
>> +++ b/meta/classes/crossvars.bbclass
>> @@ -15,7 +15,7 @@ python __anonymous() {
>>       flavor = d.getVar('SBUILD_FLAVOR')
>>       flavor_suffix = ('-' + flavor) if flavor else ''
>>
>> -    distro_arch = d.getVar('DISTRO_ARCH')
>> +    distro_arch = d.getVar('PACKAGE_ARCH')
> 
> sure - will give this is a try but I fear it won't work because the
> condition mode == "0" remains True
> You will find further below the changes that I am currently testing (the
> hello-native use-case is now working as expected, currently running CI
> tests)
> 
>>       if mode == "0" or d.getVar('HOST_ARCH') == distro_arch or distro_arch == None:
>>           d.setVar('BUILD_HOST_ARCH', distro_arch)
>>           schroot_dir = d.getVar('SCHROOT_TARGET_DIR', False)
> 
> My RFC changes below
> 
> diff --git a/meta/classes/crossvars.bbclass b/meta/classes/crossvars.bbclass
> index df26f47..1378333 100644
> --- a/meta/classes/crossvars.bbclass
> +++ b/meta/classes/crossvars.bbclass
> @@ -15,12 +15,24 @@ python __anonymous() {
>       flavor = d.getVar('SBUILD_FLAVOR')
>       flavor_suffix = ('-' + flavor) if flavor else ''
> 
> +    # get arch triplet
> +    host_arch = d.getVar('HOST_ARCH')
>       distro_arch = d.getVar('DISTRO_ARCH')
> -    if mode == "0" or d.getVar('HOST_ARCH') == distro_arch or
> distro_arch == None:
> +    package_arch = d.getVar('PACKAGE_ARCH')
> +
> +    # -native build within a foreign-arch build? use host
> +    if package_arch == host_arch and package_arch != distro_arch:

package_arch == host_arch looks redundant here.

> +        d.setVar('BUILD_HOST_ARCH', d.getVar('HOST_ARCH'))
> +        schroot_dir = d.getVar('SCHROOT_HOST_DIR', False)
> +        sbuild_dep = "sbuild-chroot-host" + flavor_suffix + ":do_build"
> +        sdk_toolchain = "build-essential"

These blocks have more and more redundancies, specifically as we only
have two possible outcomes: cross or native build.

> +    # not cross-compiling? use target
> +    elif mode == "0" or d.getVar('HOST_ARCH') == distro_arch or
> distro_arch == None:

You have extracted host_arch above already.

If the special case you found can be simply addressed here, we can do
that. I doubt, though, that it has a lot practical relevance. It's more
for consistency.

Jan

>           d.setVar('BUILD_HOST_ARCH', distro_arch)
>           schroot_dir = d.getVar('SCHROOT_TARGET_DIR', False)
>           sbuild_dep = "sbuild-chroot-target" + flavor_suffix + ":do_build"
>           sdk_toolchain = "build-essential"
> +    # cross-compiling for the foreign-arch: use host with cross toolchain
>       else:
>           d.setVar('BUILD_HOST_ARCH', d.getVar('HOST_ARCH'))
>           schroot_dir = d.getVar('SCHROOT_HOST_DIR', False)
> 
> 
>> Thanks,
>> Adriaan
>>
>>> Thanks
>>> Cedric
>>>
>>> Refs:
>>>       next @ b602e36defa0abacb9ba874b4e98bc9741a006a0 kas: Fix a typo in
>>> KAS_IMAGE_PREINSTALL list
>>>       master @ 61086915e6c83fff22effa85cda64a2ac0c2f100 dpkg: Fix
>>> internal deb import for sbuild
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "isar-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to isar-users+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/isar-users/207e5270-361a-478b-bfb1-
>>> 0eccd72ef1a0%40siemens.com.
> 
> 

-- 
Siemens AG, Technology
Linux Expert Center


  reply	other threads:[~2023-10-06  5:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-06  2:49 cedric.hombourger
2023-10-06  4:59 ` Schmidt, Adriaan
2023-10-06  5:03   ` cedric.hombourger
2023-10-06  5:27     ` Jan Kiszka [this message]
2023-10-06  6:17       ` cedric.hombourger
2023-10-06 12:02         ` Jan Kiszka
2023-10-06 12:12           ` Jan Kiszka
2023-10-06 12:30             ` Jan Kiszka
2023-10-06 14:56           ` cedric.hombourger
2023-10-06 15:19             ` Jan Kiszka
2023-10-06  5:20 ` 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=fac2432e-e03b-4b61-854c-b81b66f1bcd9@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=adriaan.schmidt@siemens.com \
    --cc=cedric.hombourger@siemens.com \
    --cc=isar-users@googlegroups.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