I think TARGET_OS is unwanted here

Hi Kumar Thanks for the patches all these patches should be CCed to openembedded-core@... as well

For a PPC target flac will try to build with altivec optimizations. Altivec and SPE are mutually exclusive options. Between flac's configure choices and the ppce500v2 tune file options we'd end up

If trying to build for an e500v2 target openssl will fail to build since the configure script didn't know how to handle a 'gnuspe' target. Signed-off-by: Kumar Gala <galak@...> ---

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