native gcc compiler error


Kumar Gala <galak@...>
 

I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.

- k


Khem Raj
 

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala <galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain.  However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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.

- k


Kumar Gala <galak@...>
 

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala <galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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.

- k


Richard Purdie
 

On Mon, 2011-07-18 at 09:54 -0500, Kumar Gala wrote:
On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala <galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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.
Does strace show where its looking for it?

Cheers,

Richard


Saul Wold <sgw@...>
 

On 07/18/2011 07:54 AM, Kumar Gala wrote:

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala<galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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!


- k
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Kumar Gala <galak@...>
 

On Jul 18, 2011, at 12:22 PM, Saul Wold wrote:

On 07/18/2011 07:54 AM, Kumar Gala wrote:

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala<galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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.

- k


Khem Raj
 

On Mon, Jul 18, 2011 at 11:01 AM, Kumar Gala <galak@...> wrote:

On Jul 18, 2011, at 12:22 PM, Saul Wold wrote:

On 07/18/2011 07:54 AM, Kumar Gala wrote:

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala<galak@...>  wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain.  However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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.

- k


Kumar Gala <galak@...>
 

On Jul 18, 2011, at 1:01 PM, Kumar Gala wrote:


On Jul 18, 2011, at 12:22 PM, Saul Wold wrote:

On 07/18/2011 07:54 AM, Kumar Gala wrote:

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala<galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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.

- k
If I add the link by hand the issues goes away.

- K


Kumar Gala <galak@...>
 

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


Khem Raj
 

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 ?


Kumar Gala <galak@...>
 

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.

- k


Khem Raj
 

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.


- k


Kumar Gala <galak@...>
 

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


Khem Raj
 

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

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).
yes I will but may be a day or two

- k


Kumar Gala <galak@...>
 

On Jul 18, 2011, at 12:22 PM, Saul Wold wrote:

On 07/18/2011 07:54 AM, Kumar Gala wrote:

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala<galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
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!
So it appears the fix for bug 1233 isn't complete. Should I re-open the bug or a new one?

- k