These are build objects if you don't need them add INHERIT += "rm_work" to your conf/local.conf which should delete the intermediate objects after a recipe builds. Thx -Khem

so may be it should be termed as 'Build Configuration' instead

maybe -gnuspe is problem ? try powerpc-linux-gnu and see if helps

Can you try after addding the following to the failing recipe with CXXFLAGS := "${@oe_filter_out('-feliminate-dwarf2-dups', '${CXXFLAGS}', d)}" -Khem

mipsel is treated as a different machine. Its not supported (yet) in oe-core. Its on my todo list unless someone beats me to it. You need to add machine support and infra support. You can look at clas

The autoconf'ing is sort of arbitrary at the moment. Depending on what is staged the results may vary. So some way of creating a cache is nice since it can be used to verify if package rebuild happens

<eha@...> wrote: you seem to be stuck in this tight while(1) loop per recipe staging is not panacea Do you have some prototypes ? where you can control what staging is presented and

this means ABI change especially due to double formats. This should be doable in machine.conf files or tune files. this is new I guess. Its like adding a new arch to OE. See around http://lists.linuxt

here is the problem. This should have been called virtual/powerpc-poky-linux-gnuspe-libc-for-gcc so TARGET_PREFIX is not being set correctly which means TARGET_SYS is not being set correctly and TARGE

Well as I see not so easily which is since we share toolchain for architectures and if we let machines add ABI conflicting options then we will be in trouble think of using I could have suggested usin

heh thats not enought info in there. But again the problem seems to be that TARGET_OS is not being set to linux-gnuspe and virtual/${TARGET_PREFIX}libc-for-gcc is being expanded to use default value w

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.

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.

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

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

yes I will but may be a day or two

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

I think TARGET_OS is unwanted here

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

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']]}"