To whom may concern, I tried to build Yocto for a real device, which is EeePC901. Because of README.hardware mentioned. Here are my steps: # source poky-bernard-5.0.1/poky-init-build.env

similar change is needed for tclibc-uclibc.inc as well. something like TARGET_OS_powerpc = "linux-uclibc${@['','spe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"

this will enable e500_double even for e500v1 which IIRC does not have DFP support have you tried building for e500v1 with this ?

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.