On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala <[email protected]> wrote: >>>>>> 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. >>>>> >>>>> 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 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), >>>>> dynamically linked, with unknown capability 0x41000000 = 0xf676e75, with >>>>> unknown capability 0x10000 = 0x70402, stripped >>>>> >>>>> root@p2020-ds:~# ls -lstr >>>>> /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/ >>>>> total 31624 >>>>> 9812 -rwxr-xr-x 1 root root 10046304 Jul 16 22:40 lto1 >>>>> 28 -rwxr-xr-x 1 root root 26344 Jul 16 22:40 lto-wrapper >>>>> 60 -rwxr-xr-x 1 root root 60132 Jul 16 22:40 liblto_plugin.so.0.0.0 >>>>> 124 -rwxr-xr-x 1 root root 124776 Jul 16 22:40 collect2 >>>>> 11208 -rwxr-xr-x 1 root root 11476244 Jul 16 22:40 cc1plus >>>>> 10392 -rwxr-xr-x 1 root root 10640644 Jul 16 22:40 cc1 >>>>> 0 lrwxrwxrwx 1 root root 22 Jul 17 15:07 liblto_plugin.so.0 -> >>>>> liblto_plugin.so.0.0.0 >>>>> >>>>> So not clear why its not finding it. >>>>> >>>> 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 branch? >>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2429773613cb95b6a0541b5cce6ce1338d5cfc2b >>>> >>>> It's possible you might be missing this and it's not finding the file >>>> correctly. >>>> >>>> As Richard mentioned also, an strace output would be helpful if you do >>>> have the above commit. >>>> >>>> Thanks >>>> Sau! >>> >>> 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", >>> R_OK) = -1 ENOENT (No such file or directory) >>> access("/usr/libexec/gcc/powerpc-poky-linux-gnuspe/liblto_plugin.so", R_OK) >>> = -1 ENOENT (No such file or directory) >>> access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", >>> R_OK) = -1 ENOENT (No such file or directory) >>> access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/liblto_plugin.so", R_OK) = >>> -1 ENOENT (No such file or directory) >>> access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/../../../../powerpc-poky-linux-gnuspe/bin/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so", >>> R_OK) = -1 ENOENT (No such file or directory) >>> access("/usr/lib/gcc/powerpc-poky-linux-gnuspe/4.6.1/../../../../powerpc-poky-linux-gnuspe/bin/liblto_plugin.so", >>> R_OK) = -1 ENOENT (No such file or directory) >>> >>> So it appears we are missing in the package 'liblto_plugin.so' link. >> >> 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. > > 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 packages-split/gcc-dev vs > packages-split/gcc ] > > For the e500v2 (P2020-DS) build: > > http://pastebin.com/B1qyfbGE > > - 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 or may be create a new package called liblto or somesuch Can you install gcc-dev package on your device and see if this helps ? _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
