diff options
author | Ilya Yanok <yanok@emcraft.com> | 2011-04-05 03:13:45 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-04-05 17:13:45 +0100 |
commit | 0d4ea5d7486dc35001582bef3ff6ebfad0606bda (patch) | |
tree | f42d4686e67d4fb907b19c7c06eb7fada921c664 /meta/recipes-extended/blktool | |
parent | 694db055f3729662e0e0193a31f2098be599877f (diff) | |
download | openembedded-core-0d4ea5d7486dc35001582bef3ff6ebfad0606bda.tar.gz openembedded-core-0d4ea5d7486dc35001582bef3ff6ebfad0606bda.tar.bz2 openembedded-core-0d4ea5d7486dc35001582bef3ff6ebfad0606bda.tar.xz openembedded-core-0d4ea5d7486dc35001582bef3ff6ebfad0606bda.zip |
native, nativesdk, crosssdk: reset TARGET_FPU
When building one of the native, nativesdk or crosssdk packages TARGET_*
variables' values are no longer related to the target we set via MACHINE
variable, they are now related to the BUILD (native) or SDK (nativesdk,
crosssdk) targets instead. We need to change TARGET_FPU variable
accordingly or some of the recipes (the ones that check for TARGET_FPU
value, most notably gcc and eglibc) might be confused.
It's probably cleaner not to reset TARGET_FPU but to change it to
something like ${BUILD_FPU} (for native) or ${SDK_FPU} (for crosssdk and
nativesdk) but as long as BUILD and SDK are x86 it's safe to just reset
TARGET_FPU.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-extended/blktool')
0 files changed, 0 insertions, 0 deletions