linux/poky.git/meta/recipes-devtools/binutils/binutils-cross-canadian.inc, branch dora

cross-canadian: Handle powerpc linux verses linux-gnuspe

2013-12-12T17:00:08+00:00

PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This patch links them together so the one cross-canadian toolchain can support both. GCC_FOR_TARGET is set for the GCC recipe as otherwise configure can pick up an incorrect value. [YOCTO #5354] (From OE-Core master rev: a1d6331238982b0c5d39b0a18794f6654b00d46a) (From OE-Core rev: b114b045687776ebc5c805e1f19758e7e37eebf2) Signed-off-by: Richard Purdie Signed-off-by: Saul Wold Signed-off-by: Richard Purdie Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

cross-canadian: Fix TUNE_PKGARCH references

2013-10-04T17:26:50+00:00

The cross-canadian compilers are now build once per architecture but were being installed into tune specific locations which is incorrect. This adjusts things so they are make TARGET_ARCH specific. We gain the tune specific parts from the target sysroot which remains tune specific, the compiler and tools are independent ot that. binutils/gcc require sysroot options but since we reset at runtime, these shouldn't have dependencies in the sstate checksums. They are therefore also excluded. With these patches, switching machines does not result in a rebuild of *-cross-canadian and the compiler is correctly located and referenced in the target images. (From OE-Core rev: f58acab6414fe96d9e07ebbe86b348d2ac2bed5f) Signed-off-by: Richard Purdie

nativesdk: Switch to using nativesdk as a prefix, not a suffix

2012-09-02T12:52:06+00:00

As discussed on the mailing lists, using a suffix to package names is hard and has lead to many recipes having to do PKGSUFFIX games. Its looking extremely hard to scale nativesdk much further without hacking many recipes. By comparison, using a prefix like multilib does works much better and doesn't involve "hacking" as many recipes. This change converts nativesdk to use a prefix using the existing multilib infrastructure. (From OE-Core rev: 81813c0e322dc04ce4b069117188d8a54dfddb8c) Signed-off-by: Richard Purdie

binutils: Add with-sysroot to target binutils

2012-06-21T12:03:04+00:00

Also rearrange the recipes to have common bits in inc files and not include the target bb file everywhere. This lets us add specific options to specific recipes particularly target recipe in this case (From OE-Core rev: f4ed063e32f064e996a4c29760fa4ac49f1ed73c) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

binutils-cross-canadian: Clear BBCLASSEXTEND as a native version of this recipe makes no sense

2012-01-11T23:53:32+00:00

(From OE-Core rev: 5980cd6af7b5260558cb234288a426c091b5de2a) Signed-off-by: Richard Purdie

binutils-cross-canadian: Allow ld-is-gold

2012-01-05T11:24:48+00:00

In order to actually generate a toolchain (with bitbake meta-toolchain) that supports gold, binutils- cross-canadian also needs to be built this way. (From OE-Core rev: 0eb3a0f3ee857a17d80598ea2f0b1f3d14ac6d30) Signed-off-by: Derek Buitenhuis Signed-off-by: Richard Purdie

binutils-cross-canadian: Point sysroot to correct location

2011-10-24T16:27:13+00:00

(From OE-Core rev: b8dad4ab77f5516bc6929e2ed094fdc62a5a52db) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

binutils-cross-canadian.inc: disable -werror like -cross does

2011-02-09T11:07:49+00:00

The error this works around is: cc1: warnings being treated as errors gas/config/tc-arm.c: In function 'parse_operands': gas/config/tc-arm.c:1876:27: error: 'firsttype$defined' may be used uninitialized in this function gas/config/tc-arm.c:1876:27: error: 'firsttype$index' may be used uninitialized in this function Ideally it should get fixed properly, but let's mimic binutils-cross for now Signed-off-by: Koen Kooi Signed-off-by: Richard Purdie

binutils*.inc: Recipe format cleanup

2010-12-23T16:07:00+00:00

Cleanup some simple whitespace / line break issues. Signed-off-by: Scott Garman

Using TRANSLATED_TARGET_ARCH instead of TARGET_ARCH.

2010-12-10T15:36:48+00:00

Using TRANSLATED_TARGET_ARCH instead of TARGET_ARCH for cross-canadian packages. This is due to the TARGET_ARCH of x86_64 would results incorrect packaging in cross-canadian packages. The pacakge name appendix of x86_64 target in cross-canadian packages is x86-64. Signed-off-by: Lianhao Lu