[OE-core] [PATCH] gcc-common: Only apply fpu settings to target gcc

[Richard Purdie]

On Mon, 2014-10-27 at 20:54 +0100, Kristof Robot wrote:
> Richard, all,
> 
> After bisecting, I found that, since this patch, my toolchain is being
> built with soft floating point support, while it should be built with
> hard floating point support:
> 
> (1) Compiling parent commit 74d8866814aec520822518cc4cb8a942f7069bf7
> [1] gives hard floating point support (good):
>     $./build.good74d8/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
>  -dM -E - < /dev/null | grep -i SOFTFP
>     $
> 
> (2) Compiling with this patch (commit
> ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf [2]) gives soft floating
> point support (bad):
>     $ ./build.badce1f/tmp-eglibc/sysroots/x86_64-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
>  -dM -E - < /dev/null | grep -i SOFTFP
>     #define __SOFTFP__ 1
>     $
> 
> I am using DEFAULTTUNE = "cortexa7hf-neon-vfpv4", resulting in
> following build configuration parameters:
>     TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard vfpv4 cortexa7"
>     TARGET_FPU        = "vfp-vfpv4-neon"

When building in OE, we always pass in the correct flags to gcc to
ensure the correct thing gets built. The option you're changing with the
revert just changed the default used by gcc if no option is specified on
the commandline, so the change of the above test isn't a surprise.

What is the real world problem you're seeing due to this? Is it caused
by some compiler flags not being passed in somewhere?

Note that some changes in master-next start to make the problem much
more obvious by poisoning the default sysroot option to the compiler.
When such options get lost, the failures should then be much clearer.

Cheers,

Richard