[OE-core] [PATCH 1/1] tune-ppce500v2.inc: explicitly set gcc float

[Richard Purdie]

On Wed, 2016-03-09 at 06:18 -0500, Hongxu Jia wrote:
> For powerpc*-*-*spe*, default to with_cpu=8548 if --enable-e500
> -double,
> and to 8540 otherwise.
> vim gcc/config.gcc
> ...
>     powerpc*-*-*spe*)
>       if test x$enable_e500_double = xyes; then
>          with_cpu=8548
>       else
>          with_cpu=8540
>       fi
>       ;;
> ...
> 
> The with_cpu is used for SPE version detection
> vim ./gcc/config/rs6000/t-linux
> ...
>   7 ifneq (,$(findstring spe,$(target)))
>   8 MULTIARCH_DIRNAME := powerpc-linux-gnuspe$(if $(findstring
> 8548,$(with_cpu)),,v1)
>   9 else
>  10 MULTIARCH_DIRNAME := powerpc-linux-gnu
> ...
> 
> The variable MULTIARCH_DIRNAME is the output of '$CC --print
> -multiarch'.
> Without this patch, the output is 'powerpc-linux-gnuspev1' which
> caused
> python3 do_configure failed.
> 
> Since ppce500v2 -mcpu is 8548, explicitly add --enable-e500-double
> could fix
> the issue.
> 
> [YOCTO #9226]
> 
> Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com>
> ---
>  meta/conf/machine/include/tune-ppce500v2.inc | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/meta/conf/machine/include/tune-ppce500v2.inc
> b/meta/conf/machine/include/tune-ppce500v2.inc
> index 20a5f25..70d3078 100644
> --- a/meta/conf/machine/include/tune-ppce500v2.inc
> +++ b/meta/conf/machine/include/tune-ppce500v2.inc
> @@ -18,3 +18,7 @@ AVAILTUNES += "ppce500v2"
>  TUNE_FEATURES_tune-ppce500v2 = "m32 spe ppce500v2"
>  TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2"
>  PACKAGE_EXTRA_ARCHS_tune-ppce500v2 = "ppce500v2"
> +
> +# For powerpc*-*-*spe*, default to with_cpu=8548 if
> +# --enable-e500-double, and to 8540 otherwise.
> +EXTRA_OECONF_GCC_FLOAT += "${@get_gcc_float_setting(bb, d)}"

This is good to understand what is breaking but the patch as it stands
can't be merged as the gcc recipe intentionally doesn't do this, its
only done in gcc-target.inc.

Why?

The theory is we should be building one gcc-cross-powerpc, not multiple
different variants. I did just try a build and realised that switching
machines between p1022ds and qemuppc does rebuild gcc-cross-powerpc but
that is a bug. Adding the above is just going to make this harder to
fix, and will certainly break the SDK gcc-cross-canadian-gcc.

I'm not sure how we should fix this, particularly given that gcc-cross
-powerpc already isn't working properly but the avoid fix isn't right.

Cheers,

Richard