From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>,
Jan Brzezanski <jan.brzezanski@gmail.com>
Subject: Re: [OE-core] [PATCH] base.bbclass: Add sstate-cache dependency to GCCVERSION
Date: Thu, 30 Jun 2022 16:28:00 +0100 [thread overview]
Message-ID: <eb07e0ecfc61d8848497773025c1bb8a4b57035b.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAJkqNs3CpSbHOEeEBQefHf0vu_cETZ2oAe0MExETSVGUEi1q+Q@mail.gmail.com>
On Thu, 2022-06-30 at 16:14 +0200, Tomasz Dziendzielski wrote:
> Would setting dependency to SDKGCCVERSION be more acceptable?
No, it wouldn't. It doesn't address the manjority of my concerns.
> That way native recipes will not depend on target gcc version.
The native recipes shouldn't depend on the SDK gcc version either.
> > I'm guessing what has happened in your case is that a
> > TMPDIR as reused after changing gcc version but something didn't
> > rebuild, probably as ${S} == ${B} and hence ${B} couldn't be
> > cleaned
>
> The problem is not that it didn't rerun the make or didn't clean the
> ${B} or ${S}. After changing GCCVERSION the nativesdk-mgen is taken
> from sstate-cache.
I don't believe that is the issue. I don't have "nativesdk-mgen", but
taking nativesdk-sed as an example:
$ bitbake nativesdk-sed -S none
(to dump the signatures for that recipe)
$ bitbake-dumpsig tmp/stamps/aarch64-nativesdk-pokysdk-linux/nativesdk-sed/4.8-r0.do_prepare_recipe_sysroot.sigdata.*
shows:
Hash for dependent task /media/build1/poky/meta/recipes-devtools/gcc/gcc-crosssdk_12.1.bb:do_populate_sysroot is 4a58e102e0d4e2652a7f960e728b5ae3465a03a9fe6c26135ab6b4dc5b89b951
Hash for dependent task virtual:nativesdk:/media/build1/poky/meta/recipes-devtools/gcc/gcc-runtime_12.1.bb:do_populate_sysroot is 3bcf5017659d63c6e744140dde8db8a9e37a412a38924ab5f1031337dec44198
amongst other things.
i.e. the nativesdk recipes *clearly* do have a dependency on the gcc
version used for nativesdk.
Cheers,
Richard
prev parent reply other threads:[~2022-06-30 15:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 13:08 [PATCH] base.bbclass: Add sstate-cache dependency to GCCVERSION Tomasz Dziendzielski
2022-06-29 14:23 ` [OE-core] " Richard Purdie
2022-06-30 14:14 ` Tomasz Dziendzielski
2022-06-30 15:28 ` Richard Purdie [this message]
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=eb07e0ecfc61d8848497773025c1bb8a4b57035b.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=jan.brzezanski@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=tomasz.dziendzielski@gmail.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