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 o
Would setting dependency to SDKGCCVERSION be more acceptable? That way
native recipes will not depend on target gcc version.
>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} co
On Wed, 2022-06-29 at 15:08 +0200, Tomasz Dziendzielski wrote:
> If we have the build with different gcc versions in the same workspace
> it might happen that nativesdk recipe will not detect the change of gcc
> and the package will be taken from sstate-cache. This will lead to
> do_package_qa fail
If we have the build with different gcc versions in the same workspace
it might happen that nativesdk recipe will not detect the change of gcc
and the package will be taken from sstate-cache. This will lead to
do_package_qa failure due to binaries requiring symbols that are not
present in the older