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 <[email protected]> > --- > 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
