gcc-common: Only apply fpu settings to target gcc

Within the OE build environment, we supply the correct fpu settings. These only need to be spelt out for the on-target gcc.

Doing this means the checksums for the core compiler don't depend on the fpu settings. We exclude the compiler tunes for similar reasons, it doesn't need to influence the compiler build.

Signed-off-by Richard Purdie <[email protected]>

---

meta/recipes-devtools/gcc/gcc-common.inc +1 -1

index 0408e65..e56e598 100644
@@ -63,7 +63,7 @@ def get_tune_parameters(tune, d):
     retdict['package_extra_archs'] = localdata.getVar('PACKAGE_EXTRA_ARCHS', True)
     return retdict
 
-get_tune_parameters[vardepsexclude] = "AVAILTUNES"
+get_tune_parameters[vardepsexclude] = "AVAILTUNES TUNE_CCARGS"
 
 DEBIANNAME_${MLPREFIX}libgcc = "libgcc1"
 

meta/recipes-devtools/gcc/gcc-configure-common.inc +1 -1

index 3cb6ec8..31e3cc4 100644
@@ -61,7 +61,7 @@ EXTRA_OECONF_append_libc-uclibc        = " --enable-__cxa_atexit"
 EXTRA_OECONF_append_mips64    = " --with-abi=64 --with-arch-64=mips64 --with-tune-64=mips64"
 EXTRA_OECONF_append_mips64el    = " --with-abi=64 --with-arch-64=mips64 --with-tune-64=mips64"
 
-EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}"
+EXTRA_OECONF_FPU ??= ""
 CPPFLAGS = ""
 
 # powerpc needs this to comply with the ABI

meta/recipes-devtools/gcc/gcc-target.inc +2 -1

index 45a1637..de906d6 100644
@@ -7,6 +7,8 @@ EXTRA_OECONF_PATHS = " \
     --with-native-system-header-dir=${STAGING_DIR_TARGET}${target_includedir} \
     --with-gxx-include-dir=${includedir}/c++/"
 
+EXTRA_OECONF_FPU = "${@get_gcc_fpu_setting(bb, d)}"
+
 PACKAGES = "\
   ${PN} ${PN}-plugins ${PN}-symlinks \
   g++ g++-symlinks \
 
 
--

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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"

Quoted 6 lines · Kristof Robot

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:

Quoted 4 lines

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?

Quoted 7 lines · Richard Purdie

Quoted 6 lines · Kristof Robot

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]

Quoted 5 lines

Quoted 4 lines

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"

Quoted 7 lines

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?

Quoted 38 lines · Kristof Robot

Quoted 14 lines · Richard Purdie

Quoted 13 lines · Kristof Robot

Quoted 8 lines · Kristof Robot

Quoted 7 lines · Kristof Robot

Quoted 1 line · Richard Purdie

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):

Quoted 7 lines

Quoted 2 lines

/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
    $

Quoted 7 lines

(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.

Quoted 10 lines

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

Quoted 1 line

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.