Signed-off-by: Kumar Gala <galak@...> --- meta/conf/machine/include/tune-ppce500v2.inc | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) create mode 100644

Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when we build native toolchains. So we can utilize TARGET_FPU being set to "spe" to determine if we should enable the gnuspe

The e500v2 core utilizes a unique floating point programming model / ABI. We utilize TARGET_FPU = "spe" to distinguish this choice. When building the toolchain for this ABI we need configure gcc with

The majority of support for the PowerPC e500v2/SPE target already exists. However some minor cleans are required to get things working completely. The e500v2 utilizes a unique floating point

All - I really don't like the direction this is trending. I don't think we have too much new development left in this cycle, but if you have bugs assigned can you please put additional effort into

yes I will but may be a day or two

Agreed, do you mind working up such a patch. I'm not an expert in this area so feel a little concerned about not knowing enough to try and do this cleanly (or generically). - k

OK thanks. So I think we just need to package this symlink along with gcc and all is good.

Yes if I install gcc-dev it works. - k

hmm the symlink goes into gcc-dev package since the package splitter sees a sumlink xyz.so but in this case this should be packages explicitly into gcc as we see gcc depends on it for normal execution

How do I tell? Which gcc dir should I be looking at under build/tmp/work/* ? For the MPC8315E-RDB build: http://pastebin.com/yYSww5nK [ the first three lines look interesting about

If I add the link by hand the issues goes away. - K

Does that symlink exist in your gcc install tree during build ? if not then gcc makefiles need to generate it. if its just a case we forgot to bundle it then we should add it to FILES var of gcc.

access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory) access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so",

This looks similar to Yocto Bug 1233 (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1233 Can you confirm if you have the following commit in your

Does strace show where its looking for it? Cheers, Richard

I was trying a core-image-minimal build with 'tools-sdk' added to EXTRA_IMAGE_FEATURES and was expecting a native gcc in the generated rootfs. This was for mpc8315e-rdb config. conf/local.conf

File appears to be there: root@p2020-ds:/# file /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0 ./usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0: ELF

You can try -fno-use-linker-plugin as a workaround. Does liblto_plugin.so exist on target rfs ? it might be then gcc driver bug if the library is not there then we forgot to package it.

I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I