openembedded-core.git/meta/recipes-devtools/binutils, branch dora

binutils: Fix building nativesdk binutils with gcc 4.9

2014-07-27T07:37:38+00:00

Patches explain the issue in detail but this is exposed
with gcc 4.9 in binutils 2.23.2

(From OE-Core rev: fc5c467b680fc5aef4b0f689e6988e17a9322ae0)

(From OE-Core rev: 4dfb8847ebf8aab90ad8888933468e2899c96998)

(From OE-Core rev: af347d3298e15552d502d5b2ce497bbda9705bc7)

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

binutils: Also add autoconf-native to DEPENDS

2014-01-26T06:08:27+00:00

Commit 616354f13732d13c17434d5b60b166f691c25761 is insufficient because
gnu-config-native's gnu-configize script uses perl modules from autoconf
and hence doesn't work unless autoconf-native is staged (which it may
not be if building from sstate).

Ideally g-c-n would itself declare a dependency on autoconf-native but this
is difficult to arrange without creating a dependency loop.  autoconf-native
already depends on gnu-config-native (because autoreconf invokes gnu-configize)
and has a build dependency on m4-native, which in turn build-depends on g-c-n
because it configizes itself by steam in do_configure and needs config.{guess,sub}
to be available.  Adding some sort of gnu-config-initial-native recipe would
fix the latter problem, but this would be ugly because it would need special-casing
in (at least) autotools.bbclass, and in any case this still wouldn't solve
the problem of autoconf itself depending on g-c-n.

So, the easiest solution to the problem at hand is to arrange for those
few recipes that depend on g-c-n but not autoconf-native to gain that
latter dependency as well.

(From OE-Core master rev: 507199e57acfcc99639dc2c53abe194d77d60866)

Signed-off-by: Phil Blundell 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang

binutils: Add gnu-config-native to DEPENDS

2013-12-12T16:53:06+00:00

do_configure() in binutils.inc includes an explicit call to
gnu-configize so we need to make sure that gnu-config-native is
present.  Previously this was being dragged in with the rest of the
autotools stuff, but commit 54a3e2ee37003fc56af0339f857b0b6442790c26
disabled that for binutils-cross on the grounds that "we don't
autoreconf" the toolchain components.  Fix this by adding
gnu-config-native itself explicitly to DEPENDS.

(From OE-Core master rev: 616354f13732d13c17434d5b60b166f691c25761)

Signed-off-by: Phil Blundell 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang

cross-canadian: Handle powerpc linux verses linux-gnuspe

2013-12-12T16:53:02+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)

Signed-off-by: Richard Purdie 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang

cross-canadian: Fix TUNE_PKGARCH references

2013-10-04T17:25:06+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.

Signed-off-by: Richard Purdie

Upstream-Status: Correct capitalization

2013-07-18T14:14:40+00:00

Signed-off-by: Saul Wold

binutils: Backport emulation template fixes

2013-07-05T14:26:22+00:00

This fixes the linking errors seen on mips64 when linking
sln/ from eglibc 2.18

 /builds1/angstrom/build/tmp-angstrom_next-eglibc/sysroots/x86_64-linux/usr/libexec/mips64-angstrom-linux.gcc-cross-initial/gcc/mips64-angstrom-linux/4.8.1/ld:
BFD (GNU Binutils) 2.23.2 assertion fail
/builds1/angstrom/build/tmp-angstrom_next-eglibc/work/mips64-angstrom-linux/binutils-cross/2.23.2-r4/binutils-2.23.2/bfd/elfxx-mips.c:3453
| collect2: error: ld returned 1 exit status

Signed-off-by: Khem Raj 
Signed-off-by: Saul Wold

binutils: fix compile error of complex expressions before @l/@h

2013-06-03T15:46:37+00:00

Back port two patches to fix the error of complex expressions before @l/@h.

Error sample:
test.s: Assembler messages:
test.s:1: Error: operand out of range (0xffffffffffff8000 is not between 0x0000000000000000 and 0x000000000000ffff)

Fix Bug 4524.

Signed-off-by: Zhenhua Luo 
Signed-off-by: Richard Purdie

binutils: add two AArch64 related backports to 2.23.2

2013-05-29T21:07:22+00:00

Update required to pass "movi" related build errors when gcc-4.8 is
used.

libgcrypt, slang, mysql5 were failing like this:

| {standard input}: Assembler messages:
| {standard input}:316: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v3.8b,-106'
| {standard input}:348: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v3.8b,-8'
| {standard input}:352: Error: immediate value out of range 0 to 255 at operand 2 -- `movi v3.8b,-27'

Signed-off-by: Marcin Juszkiewicz 
Signed-off-by: Saul Wold

binutils: the cat should always succeed when building config.cache

2013-05-24T13:07:03+00:00

There is a race condition between when the CONFIG_SITE list is generated and
then used here via the cat to create the config.cache and in *all* configure
scripts when reading from CONFIG_SITE.

The race in this case is that the sstate setscene task runs on a package that
contains a site config file (ncurses in this case) and then bitbake decides
that it needs to rebuild and cleans out the site config file, so it existed
for siteinfo_get_files() to find in SITECONFIG_SYSROOTCACHE and then was removed
for the rebuild. When bintuils tried to run the do_configure() task which creates
the binutil's version of config.cache it reads from CONFIG_SITE which now contains
the non-existant site config file. (confused yet ;-)?

Currently the configure script does a test -r to ensure the file is readable
before using it, therefore having the cat succeed regardless of the file being
available is consistent behaviour.

Signed-off-by: Saul Wold