On Mon, 2014-01-13 at 13:37 +0100, David Nyström wrote: > Just to clarify bug 5354: > If I understand the bug correctly, this would arise when first building > the nativesdk tarball on a MACHINE with ABI linux, > and then building the nativesdk for another MACHINE(with the same the > same TUNE) after altering ABIEXTENSION to linux-gnuspe ? > > If I understand bug 5354 correctly, perhaps the tmp/sdk/tarball.here > can be ABI specific ?
The idea behind the changes to cross-canadian were to have just a single gcc/binutils which generated all of the appropriate targets for a given architecture. I understood this to be possible but it looks like we may need to tweak things a bit. > i.e. a generic rule that all nativesdk builds are invalidated if the > ABI changes. I guess that would mean: > cross-canadian.bbclass: TARGET_ARCH[vardeps] += "ABIEXTENSION" > + Adding ABIEXTENSION to the nativesdk tarball name. > > PPC '=mabi=spe' seems to be one-way compatible, I could not get the > non-SPE configured compiler > to work with the SPE sysroot. > Another possible solution would be to always configure the compiler to > SPE, and use compile time flags in the > environment file to do the selects. + symlinks for the compiler paths. Can we configure the compiler to include SPE support without changing the paths/OS string? > However, even if we fix it this way for powerpc, we will still have > this issue with thumb f.ex. Keep in mind the target sysroot still varies for each different target. The thing we're trying to keep in common is the gcc/bintuils and only have one copy for each target architecture. Is that possible in this case if we somehow enable SPE support in gcc-cross-canadian? Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
