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

[Richard Purdie]

On Tue, 2014-10-28 at 11:30 +0100, Kristof Robot wrote:
> 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?

There is something wrong somewhere by the sounds of it but I'm not 100%
sure where. With that tune, bitbake -e | grep CC= should show that CC is
something along the lines of:

CC="arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a7 --sysroot=X"

the key part being -mfloat-abi=hard. When (e)glibc is built, which
should be built specifically for this configuration, it should see that
setting in the various flags and should generate headers like:

./image/usr/include/gnu/stubs-hard.h
./image/usr/include/gnu/stubs.h

i.e. it should build a C library that matches this configuration and has
the right headers. When libfreenect is built, the right headers should
then be available.

So, I'd suggest checking that the compiler flags in CC are what you'd
expect and then that the C library is built with the right format
headers. Something, somewhere isn't honouring the flags correctly as far
as I can tell but I don't know what.

Also, I'd be aware of the fact that we build one cross compiler
(gcc-cross) for arm which is meant to work for all arm targets. If you
build a softfloat something, then a hardfloat machine, it may be that
something bad is creeping into the build process and a straight revert
may not reproduce the bug you're seeing.

Cheers,

Richard