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

[Kristof Robot]

On Mon, Oct 27, 2014 at 11:59 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> 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:
>>
[snip]
>> 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?

The real world problem is a compilation of the meta-ros libfreenect
library [1] for a Cubieboard2 [2] - this build fails because the
compiler fails to find <gnu/stubs-hard.h> (only gnu/stubs-soft.h is
available).
In other words, somehow libfreenect (correctly) expects hard floating
point, but then runs into troubles as the toolchain is (incorrectly)
compiled using soft floating point.
See also [3], which describes a similar problem, and [4], which seems
to provide relevant info.

More generally, I would actually assume that everything is being built
hard floating point, as a result of the provided DEFAULTTUNE =
"cortexa7hf-neon-vfpv4".

Isn't this the correct way to force hard floating point?

Thanks!

Kristof

[1] https://github.com/bmwcarit/meta-ros/blob/master/recipes-extended/libfreenect/libfreenect_0.2.1.bb
[2] http://cubieboard.org/2013/06/19/cubieboard2-is-here/
[3] https://gcc.gnu.org/ml/gcc-help/2013-02/msg00141.html
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796