On Thu, 2013-06-13 at 15:06 +0100, Mike Crowe wrote:
> gcc always needs binutils in order to be useful. If binutils-cross is
> considered to be a safe dependency then gcc-cross can be reconstructed into
> the sysroot without binutils. Anyone who tries to use the compiler will end
> up using the system binutils which is either a bad thing (relying on system
> tools) or a very bad thing (it will be for the wrong architecture.)
>
> In the absence of a better fix let's just stop binutils-cross being
> considered a safe dependency. The downside of this is that any
> reconstructing any other recipe that depends on binutils from the sstate
> cache will also cause binutils to be reconstructed.
>
> Signed-off-by: Mike Crowe <[email protected]>
> ---
> meta/classes/sstate.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I tried and failed to come up with a better fix for this problem. This
> fix at least means that everything will build using the correct
> version of binutils even if slightly more files are reconstructed from
> the sstate cache than would be desirable.
The correct fix for this is to whitelist the gcc depending on binutils
case but leave this "safe" version in place.
Cheers,
Richard
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 28dc312..0de62d8 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -655,7 +655,7 @@ def setscene_depvalid(task, taskdependees, notneeded, d):
> def isNativeCross(x):
> return x.endswith("-native") or x.endswith("-cross") or
> x.endswith("-cross-initial")
> def isSafeDep(x):
> - if x in ["quilt-native", "autoconf-native", "automake-native",
> "gnu-config-native", "libtool-native", "pkgconfig-native", "gcc-cross",
> "binutils-cross", "gcc-cross-initial"]:
> + if x in ["quilt-native", "autoconf-native", "automake-native",
> "gnu-config-native", "libtool-native", "pkgconfig-native", "gcc-cross",
> "gcc-cross-initial"]:
> return True
> return False
> def isPostInstDep(x):
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
