Date   

[PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

Kumar Gala <galak@...>
 

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 --enable-e500_double.

Signed-off-by: Kumar Gala <galak@...>
---
meta/recipes-devtools/gcc/gcc-4.6.inc | 2 +-
meta/recipes-devtools/gcc/gcc-common.inc | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 56064b5..b719155 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc

-PR = "r8"
+PR = "r9"

# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index 7bf036c..409ad01 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
def get_gcc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return "--with-float=soft"
+ if bb.data.getVar('TARGET_FPU', d, 1) in [ 'spe' ]:
+ return "--enable-e500_double"
return ""

def get_gcc_mips_plt_setting(bb, d):
--
1.7.3.4


[PATCH 0/5] Add support for PowerPC e500v2/SPE

Kumar Gala <galak@...>
 

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 programming model / ABI from
other PowerPC targets and thus requires special handling.

- k


Re: Yocto weekly bug trend charts -- WW29

David Stewart
 

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 resolving these? Thanks...

Dave

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Xu, Jiajun
Sent: Sunday, July 17, 2011 8:22 AM
To: yocto@...
Subject: [yocto] Yocto weekly bug trend charts -- WW29

Hi all,
Last week QA finished testing for M2 RC2. The new-submit vs. fixed
bug is 20 vs. 10 for last week. The open bug number increased to 182 (No
enhancement bugs counted). WDD number increased a lot, from 866 to 933.
Several Critical and Major bugs are found in RC2 testing. Bug status of WW29
could be found on https://wiki.pokylinux.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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 ?


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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


Re: native gcc compiler error

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


EXTRA_IMAGE_FEATURES question

Kumar Gala <galak@...>
 

I was trying a core-image-minimal build with 'tools-sdk' added to EXTRA_IMAGE_FEATURES and was expecting a native gcc in the generated rootfs. This was for mpc8315e-rdb config.

conf/local.conf has:

EXTRA_IMAGE_FEATURES = "tools-sdk debug-tweaks"

Is this wrong? is my expectation wrong based on the comments?

- k


Re: native gcc compiler error

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


Re: native gcc compiler error

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


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


Yocto weekly bug trend charts -- WW29

Xu, Jiajun <jiajun.xu@...>
 

Hi all,
Last week QA finished testing for M2 RC2. The new-submit vs. fixed bug is 20 vs. 10 for last week. The open bug number increased to 182 (No enhancement bugs counted). WDD number increased a lot, from 866 to 933. Several Critical and Major bugs are found in RC2 testing. Bug status of WW29 could be found on https://wiki.pokylinux.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun


Re: yocto build fails

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

On Fri, Jul 15, 2011 at 5:10 PM, Joshua Lock <josh@...> wrote:
On Fri, 2011-07-15 at 11:44 +0100, Gray, Mark D wrote:
This would lead me to make a guess at your proxy settings not being
configured correctly for git with nc.


On closer inspection, the file
http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz is unavailable in the repo. I did a search and I could only find http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz.bad
Looks like we have a bad mirrored tarball. :-/
I had blown the tarball away yesterday working on bug #1207. The rsync
should have run by now to pull it back up but for some reason, hasn't.
I'll look at this on Monday but in the meantime, i've forced the
rsync.

-b