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

[Kristof Robot]

[re-adding the mailinglist]

On Wed, Oct 29, 2014 at 9:41 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2014-10-29 at 07:47 +0100, Kristof Robot wrote:
>> On Tue, Oct 28, 2014 at 11:08 PM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > On Tue, 2014-10-28 at 19:11 +0100, Kristof Robot wrote:
>> >> On Tue, Oct 28, 2014 at 7:10 PM, Kristof Robot <krirobo at gmail.com> wrote:
>> >> > On Tue, Oct 28, 2014 at 11:30 AM, Kristof Robot <krirobo at gmail.com> 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:
>> >> >> 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).
>> >>
>> >> This is incorrect. The build fails because the compiler fails to find
>> >>  <gnu/stubs-soft.h> (only gnu/stubs-hard.h is available):
>> >>
>> >> /build/tmp-glibc/sysroots/cubieboard2/usr/include/gnu/stubs.h:7:29:
>> >>  fatal error: gnu/stubs-soft.h: No such file or directory
>> >
>> > In that case, I believe this is cause the -mfloat=hard option to gcc is
>> > not being passed in. That option should be set in CC= as exposed by
>> > bitbake -e and therefore if I have to guess, the software in question is
>> > "losing" the flag somewhere.
>>
>> Are you referring to the libfreenect software?
>>
>> Note that the problem is already present in the toolchain - while
>> (e)glibc seems to be built correctly with hard floating point (as can
>> be seen from the fact that gnu/stubs-hard.h is available),
>> arm-oe-linux-gnueabi-gcc is NOT built with hard floating point, but
>> with soft floating point, as indicated in my first email:
>>
>> (1) Compiling parent commit 74d8866814aec520822518cc4cb8a942f7069bf7
>> 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) 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
>>     $
>
> If you pass the -mfloat=hard option to the tests above, you will find
> that all of a sudden gcc behaves like a hardfloat system. All the patch
> you're changing does is change the default that gcc has, it can support
> both, depending on which flags it is passed.

Aha, it is changing the *default* of gcc - now I got it - that makes
sense. So the issue is not with gcc (or the toolchain in general).

>> This can also be seen based on the presence (or absence of) __ARM_PCS_VP
>>
>> (1) commit 74d8866814aec520822518cc4cb8a9 (good)
>>     arm-oe-linux-gnueabi-gcc -dM -E - < /dev/null | grep -i ARM_PCS
>>     #define __ARM_PCS_VFP 1
>>
>> (2) commit ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf (bad)
>>     arm-oe-linux-gnueabi-gcc -dM -E - < /dev/null | grep -i ARM_PCS
>>     #define __ARM_PCS 1
>>
>> Or is this expected?
>
> Expected.
>
> I still believe there is a problem in libfreenect with it not passing
> the options to the compiler that it should.

Yups, you are right. After I understood that this patch was just
changing the default gcc options, and that the issue was not with the
toolchain, I had a better look at the libfreenect software, and it
happens to have already tackled this exact issue ("Stop clobbering
CFLAGS" [1]) in a later version.

Thanks a lot for the help, and sorry for the noise!

Kristof

[1] https://github.com/OpenKinect/libfreenect/commit/0cbb86ec982d3e79ad5efa9d1b2b16724ae89bc5