Use of multilib.conf taints hashes of -native recipes

Use of multilib.conf taints hashes of -native recipes

[Mike Crowe]

We compile for a variety of machines, some of which require multilib.conf
and some that do not. I was surprised to discover when switching between
machines that the do_populate_sysroot_setscene tasks run for many -native
recipe. :(

It looks like this is because RECIPE_SYSROOT changes:

 Variable RECIPE_SYSROOT value changed from '${WORKDIR}/recipe-sysroot' to '${WORKDIR}/${MLPREFIX}recipe-sysroot'

This problem goes away if I add the following line to native.bbclass:

 RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"

but this feels like I'm solving the problem in the wrong place. Would it be
better to modify multilib.conf to say something like:

 RECIPE_SYSROOT_class-target = "${WORKDIR}/${MLPREFIX}recipe-sysroot"

instead? (Although I'm rather worried that this will stop it actually
working.)

Thanks.

Mike.

Re: Use of multilib.conf taints hashes of -native recipes

[Khem Raj]

On Thu, 2019-12-12 at 16:05 +0000, Mike Crowe via Openembedded-core
wrote:
> We compile for a variety of machines, some of which require
> multilib.conf
> and some that do not. I was surprised to discover when switching
> between
> machines that the do_populate_sysroot_setscene tasks run for many
> -native
> recipe. :(
> 
> It looks like this is because RECIPE_SYSROOT changes:
> 
>  Variable RECIPE_SYSROOT value changed from '${WORKDIR}/recipe-
> sysroot' to '${WORKDIR}/${MLPREFIX}recipe-sysroot'
> 
> This problem goes away if I add the following line to native.bbclass:
> 
>  RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
> 
> but this feels like I'm solving the problem in the wrong place. Would
> it be
> better to modify multilmultilib.confib.conf to say something like:
> 
>  RECIPE_SYSROOT_class-target = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
> 
> instead? (Although I'm rather worried that this will stop it actually
> working.)

in multilib.conf if we do

RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
RECIPE_SYSROOT_class-native = "${WORKDIR}/recipe-sysroot"

might be better, since cross etc might still need it to differentiate
multilibs

other option could be to vardepexclude it for native recipes

I was also wondering if the defaults in bitbake.conf should use
MLPREFIX unconditionally and be removed from here.

> 
> Thanks.
> 
> Mike.

Re: Use of multilib.conf taints hashes of -native recipes

[Richard Purdie]

On Thu, 2019-12-12 at 16:05 +0000, Mike Crowe via Openembedded-core
wrote:
> We compile for a variety of machines, some of which require
> multilib.conf
> and some that do not. I was surprised to discover when switching
> between
> machines that the do_populate_sysroot_setscene tasks run for many
> -native
> recipe. :(
> 
> It looks like this is because RECIPE_SYSROOT changes:
> 
>  Variable RECIPE_SYSROOT value changed from '${WORKDIR}/recipe-
> sysroot' to '${WORKDIR}/${MLPREFIX}recipe-sysroot'
> 
> This problem goes away if I add the following line to native.bbclass:
> 
>  RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
> 
> but this feels like I'm solving the problem in the wrong place. Would
> it be
> better to modify multilib.conf to say something like:
> 
>  RECIPE_SYSROOT_class-target = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
> 
> instead? (Although I'm rather worried that this will stop it actually
> working.)

I'm a little bit surprised we don't have tests which detect this. 

"oe-selftest -r ssstatetests"

should have something which detected this, at least from memory. Could
you take a look and see if we're missing some testcase?

You're right that we probably should do something fix this and I think
you are probably right about changing multiconfig.conf as above FWIW.

Cheers,

Richard

Re: Use of multilib.conf taints hashes of -native recipes

[Mike Crowe]

On Thursday 12 December 2019 at 18:17:37 +0000, Richard Purdie wrote:
> On Thu, 2019-12-12 at 16:05 +0000, Mike Crowe via Openembedded-core
> wrote:
> > We compile for a variety of machines, some of which require
> > multilib.conf
> > and some that do not. I was surprised to discover when switching
> > between
> > machines that the do_populate_sysroot_setscene tasks run for many
> > -native
> > recipe. :(
> >
> > It looks like this is because RECIPE_SYSROOT changes:
> >
> >  Variable RECIPE_SYSROOT value changed from '${WORKDIR}/recipe-
> > sysroot' to '${WORKDIR}/${MLPREFIX}recipe-sysroot'
> >
> > This problem goes away if I add the following line to native.bbclass:
> >
> >  RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
> >
> > but this feels like I'm solving the problem in the wrong place. Would
> > it be
> > better to modify multilib.conf to say something like:
> >
> >  RECIPE_SYSROOT_class-target = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
> >
> > instead? (Although I'm rather worried that this will stop it actually
> > working.)
>
> I'm a little bit surprised we don't have tests which detect this.
>
> "oe-selftest -r ssstatetests"
>
> should have something which detected this, at least from memory. Could
> you take a look and see if we're missing some testcase?

There are only two test cases that mention multilib:

 test_sstate_nativesdk_samesigs_multilib
 test_sstate_sametune_samesigs

Neither seems to test for this. I shall try to write one that builds
binutils-native both with and without multilib.

Thanks.

Mike.