[PATCH] native.bbclass: Ensure native recipes have a deterministic baselib value

[PATCH] native.bbclass: Ensure native recipes have a deterministic baselib value

[Richard Purdie]

Changes to baselib by specific machine configuration were resulting
in sstate cache invalidation, particularly in multilib configurations.

This patch ensures this doesn't happen and native sstate cache files
are reusable.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 5e45aed..ba8b0bf 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -69,6 +69,8 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 libdir = "${STAGING_DIR_NATIVE}${libdir_native}"
 
+baselib = "lib"
+
 # Libtool's default paths are correct for the native machine
 lt_cv_sys_lib_dlsearch_path_spec[unexport] = "1"
 

Re: [PATCH] native.bbclass: Ensure native recipes have a deterministic baselib value

[Mark Hatle]

On 10/6/11 9:20 AM, Richard Purdie wrote:
> Changes to baselib by specific machine configuration were resulting
> in sstate cache invalidation, particularly in multilib configurations.
> 
> This patch ensures this doesn't happen and native sstate cache files
> are reusable.

Likely throwing in a can of worms here, but for our existing (non-OE based)
work, we generally change the baselib to "lib64" on 64-bit machines.  Without
patching native.bbclass, is it possible to do that?

We do this because we ship both 32-bit and 64-bit host tooling for a variety of
host distributions, I expect we'll have to continue doing that as we transition
to an OE-based system.

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
> index 5e45aed..ba8b0bf 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -69,6 +69,8 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
>  
>  libdir = "${STAGING_DIR_NATIVE}${libdir_native}"
>  
> +baselib = "lib"
> +
>  # Libtool's default paths are correct for the native machine
>  lt_cv_sys_lib_dlsearch_path_spec[unexport] = "1"
>  
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] native.bbclass: Ensure native recipes have a deterministic baselib value

[McClintock Matthew-B29882]

On Thu, Oct 6, 2011 at 9:20 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Changes to baselib by specific machine configuration were resulting
> in sstate cache invalidation, particularly in multilib configurations.
>
> This patch ensures this doesn't happen and native sstate cache files
> are reusable.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This fixes native sstate-cache (re)usage when enabling multilib.

-M

Re: [PATCH] native.bbclass: Ensure native recipes have a deterministic baselib value

[Richard Purdie]

On Thu, 2011-10-06 at 09:47 -0500, Mark Hatle wrote:
> On 10/6/11 9:20 AM, Richard Purdie wrote:
> > Changes to baselib by specific machine configuration were resulting
> > in sstate cache invalidation, particularly in multilib configurations.
> > 
> > This patch ensures this doesn't happen and native sstate cache files
> > are reusable.
> 
> Likely throwing in a can of worms here, but for our existing (non-OE based)
> work, we generally change the baselib to "lib64" on 64-bit machines.  Without
> patching native.bbclass, is it possible to do that?

Yes, you could set this based on the build system architecture no
problem at all.

The reason for this change is to have a single value for native packages
which doesn't change based on MACHINE. That doesn't stop you changing it
based on something specific the native binaries themselves.

The native sysroots are different depending on the build system
architecture anyway so this actually might be a non-issue for you
anyway.

Cheers,

Richard