Built a core-image-minimal sdk fine, and also our proprietary sdk.
On Tue, 15 Sep 2020 at 13:14, Khem Raj <raj.k...@gmail.com> wrote:
>
> OK please test this patch for full SDK builds and any other testing
> you do and report back if it works in all cases.
>
> On Mon, Sep 14, 2020 at 5:42 PM Douglas Royds
> <douglas.ro...@taitradio.com> wrote:
> >
> > Yes it did, thanks!
> >
> >
> > On 15/09/20 12:31 pm, Khem Raj wrote:
> >
> > > I think MACHINE should not matter for nativesdk packages. Does
> > > something like this work
> > >
> > > diff --git a/meta/classes/nativesdk.bbclass
> > > b/meta/classes/nativesdk.bbclass
> > > index 7f2692c51a..bb1dfd84c0 100644
> > > --- a/meta/classes/nativesdk.bbclass
> > > +++ b/meta/classes/nativesdk.bbclass
> > > @@ -10,7 +10,7 @@ LIBCOVERRIDE = ":${NATIVESDKLIBC}"
> > > CLASSOVERRIDE = "class-nativesdk"
> > > MACHINEOVERRIDES = ""
> > > MACHINE_FEATURES = ""
> > > -
> > > +MACHINE = "${SDKMACHINE}"
> > > MULTILIBS = ""
> > >
> > > # we need consistent staging dir whether or not multilib is enabled
> > >
> > > On Mon, Sep 14, 2020 at 5:13 PM Douglas via lists.openembedded.org
> > > <douglas.royds=taitradio....@lists.openembedded.org> wrote:
> > >> For the experiment, I wanted to see whether I could achieve no task
> > >> signature change when building nativesdk-glibc for two different
> > >> MACHINEs, but I found that the do_install sigdata for
> > >> nativesdk-linux-libc-headers changed. We're installing the
> > >> linux-libc-headers for the build machine, so it seems to make sense to
> > >> take control of the TARGET_CC_KERNEL_ARCH:
> > >>
> > >> diff --git a/meta/classes/nativesdk.bbclass
> > >> b/meta/classes/nativesdk.bbclass
> > >> index 32c3aa32ad..655439dd73 100644
> > >> --- a/meta/classes/nativesdk.bbclass
> > >> +++ b/meta/classes/nativesdk.bbclass
> > >> @@ -47,6 +47,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
> > >> TARGET_OS = "${SDK_OS}"
> > >> TARGET_PREFIX = "${SDK_PREFIX}"
> > >> TARGET_CC_ARCH = "${SDK_CC_ARCH}"
> > >> +TARGET_CC_KERNEL_ARCH = "${SDK_CC_ARCH}"
> > >> TARGET_LD_ARCH = "${SDK_LD_ARCH}"
> > >>
> > >> Which leaves me with:
> > >>
> > >> basehash changed from 42ed3480096bb7ea53b60dc876da0613 to
> > >> 38ea60bdac041673f2c491d7bbabe17c
> > >> Variable MACHINE value changed from 'qemuarm' to 'qemux86-64'
> > >> runtaskdeps changed:
> > >> linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
> > >> with hash cbb186fe33cd69cb0b06384e4d50a244
> > >> changed to
> > >> linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
> > >> with hash 4d34d6981b79d0fccc768566bf2fa533
> > >> Hash for dependent task
> > >> linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
> > >> changed from cbb186fe33cd69cb0b06384e4d50a244 to
> > >> 4d34d6981b79d0fccc768566bf2fa533
> > >>
> > >> The configure and compile tasks for linux-libc-headers are both set to
> > >> noexec. For the experiment, I added an empty do_configure task, with
> > >> this result on the do_configure sigdata:
> > >>
> > >> basehash changed from f13c2a2066fa48f0ccac35c085537c71 to
> > >> bb13f2b1b1e7e6666376f3fb5a8ec888
> > >> Variable MACHINE value changed from 'qemux86-64' to 'qemuarm'
> > >>
> > >> What to do? Why is the MACHINE variable included in the task signature
> > >> (it is unset in run.do_configure)? Adding it to BB_HASHBASE_WHITELIST
> > >> had no effect. What am I missing here?
> > >>
> > >>
> >
> >
--
This Communication is Confidential. We only send and receive email on the
basis of the terms set out at www.taitradio.com/email_disclaimer
<http://www.taitradio.com/email_disclaimer>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142597):
https://lists.openembedded.org/g/openembedded-core/message/142597
Mute This Topic: https://lists.openembedded.org/mt/76855451/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
