On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala <galak@...> wrote:

On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala <galak@...> 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 ?

Yes if I install gcc-dev it works.

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

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