]> code.ossystems Code Review - openembedded-core.git/commit
binutils: Also add autoconf-native to DEPENDS
authorPhil Blundell <pb@pbcl.net>
Fri, 10 Jan 2014 12:54:16 +0000 (12:54 +0000)
committerRobert Yang <liezhi.yang@windriver.com>
Sun, 26 Jan 2014 06:08:27 +0000 (14:08 +0800)
commitbbf8f596ca51aa33bdb5b0d5664827d62408863c
tree2a5a1c9861fb6db3e6e6b159a10c8df6e469c452
parent18b0c51668a8da50d679c6e9a55ccd3c0595c011
binutils: Also add autoconf-native to DEPENDS

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 <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
meta/recipes-devtools/binutils/binutils.inc