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

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

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

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

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

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

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

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

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

On Fri, 2011-07-15 at 11:44 +0100, Gray, Mark D wrote:

I have been trying to build on Ubuntu 11.0.4. I think I have followed
the online documentation correctly. I have also followed the wiki
page, which is required for me, to set up the proxy servers. However,
the build is still failing for me. This is for Bernard-5.0.1. I get
the following message

<snip>

| NOTE: fetch
http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz

| Cloning into bare
repository /home/green/mdgray/yocto/poky-5.0.1-build/downloads/git2/git.pokylinux.org.linux-yocto-2.6.37...

| nc: read failed (0/3): Broken pipe

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. :-/

Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre

Robert,

These are handled.

Thanks again.

ScottR

Fixed.

Thanks Robert.

Agenda:
 
- opens - 5 min 
- Review Yocto 1.1 M2 Release Criteria - 20 min (Song) See details at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
- Review M3 status and schedule - 10 min (Song)
- Discussion of using Weighted Defect density as one of the release criteria: (4th graph at: https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend ) - 10 min
- Opens - 10 min
* Darren: documentation process for release, making sure we can update the README.hardware after release if needed.
- Action Item Review - 5 min (Song)
 
Action item list:
* Saul: talk to Jianjun, QA should work with developers to make sure we can cover more distro testing (informal) before major release. Joshua and Darren volunteers for some of these testing.
* Song: check status with Jianjun on Stabilization tasks he owned.
* Darren/Song: define deliverables of 'Fast boot time' for M3 and Yocto 1.1.
* Saul: circulate the idea of having a Sprint B for M3 via emails.
* Saul: check update commits (one release criteria)
* Team: please take a look at the post 1.1 items on the wiki page and let Song know if there is any comment or concerns.


Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 28, 2011 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
49611427
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a chairperson:
1.972.995.7777x67184230#
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x49611427#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
From TI Campus use 89957777
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 28, 2011
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 22, 2012, 10:40 AM CDT

"--host-armv5te..." should be "--host=armv5te..."

Signed-off-by: Robert P. J. Day <rpjday@...>

---

there's a fair amount in the ADT manual (and others) that can be
cleaned in terms of proper docbook semantic markup and entity usage,
but this looks like a fairly obvious error that should be fixed now.

diff --git a/documentation/adt-manual/adt-command.xml b/documentation/adt-manual/adt-command.xml
index 28501b6..83c61d8 100644
--- a/documentation/adt-manual/adt-command.xml
+++ b/documentation/adt-manual/adt-command.xml
@@ -37,7 +37,7 @@
<filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
Thus, the following command works:
<literallayout class='monospaced'>
- $ configure &dash;&dash;host-armv5te-poky-linux-gnueabi &dash;&dash;with-libtool-sysroot=&lt;sysroot-dir&gt;
+ $ configure &dash;&dash;host=armv5te-poky-linux-gnueabi &dash;&dash;with-libtool-sysroot=&lt;sysroot-dir&gt;
</literallayout>
</para>
<para>

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Jul 15, 2011, at 5:04 PM, Khem Raj wrote:

On Fri, Jul 15, 2011 at 2:57 PM, Kumar Gala <galak@...> wrote:

On Jul 15, 2011, at 4:29 PM, Khem Raj wrote:

On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala <galak@...> wrote:

In my attempts to get an e500v2/gnuspe toolchain working I was able to get core-image-minimal working. However when I try the 'meta-toolchain' I run into the following below. I believe this is because of TARGET_OS being 'linux-gnuspe'.

Any ideas ?

- k

[kumar@right build-p2020]$ bitbake meta-toolchain

OE Build Configuration:
BB_VERSION = "1.13.2"
TARGET_ARCH = "powerpc"
TARGET_OS = "linux-gnuspe"
MACHINE = "p2020-ds"
DISTRO = "poky"
DISTRO_VERSION = "1.0+snapshot-20110715"
TARGET_FPU = "spe"
meta
meta-yocto = "master:068839698fe192d8846c0ed4db65861448e8e524"

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'

here is the problem. This should have been called
virtual/powerpc-poky-linux-gnuspe-libc-for-gcc

so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
not being set correctly

and

TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
1) == ('' or 'custom')]}"

so it should be ok if TARGET_OS is set

can you pastebin output of

bitbake -e meta-toolchain

somewhere

Are you sure that is what you want? It looks the same

http://pastebin.com/FuNFCxLQ

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

is being expanded to use default value which is 'powerpc-poky-linux-'
in your case

how/where are you setting TARGET_OS

Guessing:

meta/conf/distro/include/tclibc-eglibc.inc:TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"

- k

On Fri, Jul 15, 2011 at 2:57 PM, Kumar Gala <galak@...> wrote:

On Jul 15, 2011, at 4:29 PM, Khem Raj wrote:

On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala <galak@...> wrote:

In my attempts to get an e500v2/gnuspe toolchain working I was able to get core-image-minimal working.  However when I try the 'meta-toolchain' I run into the following below.  I believe this is because of TARGET_OS being 'linux-gnuspe'.

Any ideas ?

- k

[kumar@right build-p2020]$ bitbake meta-toolchain

OE Build Configuration:
BB_VERSION        = "1.13.2"
TARGET_ARCH       = "powerpc"
TARGET_OS         = "linux-gnuspe"
MACHINE           = "p2020-ds"
DISTRO            = "poky"
DISTRO_VERSION    = "1.0+snapshot-20110715"
TARGET_FPU        = "spe"
meta
meta-yocto        = "master:068839698fe192d8846c0ed4db65861448e8e524"

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'

here is the problem. This should have been called
virtual/powerpc-poky-linux-gnuspe-libc-for-gcc

so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
not being set correctly

and

TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
1) == ('' or 'custom')]}"

so it should be ok if TARGET_OS is set

can you pastebin output of

bitbake -e meta-toolchain

somewhere

Are you sure that is what you want?  It looks the same

http://pastebin.com/FuNFCxLQ

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

is being expanded to use default value which is 'powerpc-poky-linux-'
in your case

how/where are you setting TARGET_OS

- k

On Jul 15, 2011, at 4:29 PM, Khem Raj wrote:

On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala <galak@...> wrote:

In my attempts to get an e500v2/gnuspe toolchain working I was able to get core-image-minimal working. However when I try the 'meta-toolchain' I run into the following below. I believe this is because of TARGET_OS being 'linux-gnuspe'.

Any ideas ?

- k

[kumar@right build-p2020]$ bitbake meta-toolchain

OE Build Configuration:
BB_VERSION = "1.13.2"
TARGET_ARCH = "powerpc"
TARGET_OS = "linux-gnuspe"
MACHINE = "p2020-ds"
DISTRO = "poky"
DISTRO_VERSION = "1.0+snapshot-20110715"
TARGET_FPU = "spe"
meta
meta-yocto = "master:068839698fe192d8846c0ed4db65861448e8e524"

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'

here is the problem. This should have been called
virtual/powerpc-poky-linux-gnuspe-libc-for-gcc

so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
not being set correctly

and

TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
1) == ('' or 'custom')]}"

so it should be ok if TARGET_OS is set

can you pastebin output of

bitbake -e meta-toolchain

somewhere

Are you sure that is what you want? It looks the same

http://pastebin.com/FuNFCxLQ

- k

On Fri, Jul 15, 2011 at 2:13 PM, Kumar Gala <galak@...> wrote:

On Jul 15, 2011, at 2:28 PM, Khem Raj wrote:

On Thu, Jul 14, 2011 at 7:36 PM, Kumar Gala <galak@...> wrote:

Where is the best place to ask questions and try and get support for adding some toolchain variations in?

I'm wanting to add support in for a few different flavors of PPC that are not currently supported:

* e500v2 (gcc needs --enable-e500_double, eglibc

this means ABI change especially due to double formats. This should be
doable in machine.conf
files or tune files.

how so?  What can I set in there that would actually get passed into gcc's configure (not really seeing anything).  Also what exactly do you mean by a machine.conf

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

So one way to go about this is that we use -gnuspe in target triplet
which will differentiate
SPE targets from classic ppc and then in gcc recipe include files

you can do something like

EXTRA_OECONF_append_linux-gnuspe = " --enable-e500_double "

* e5500 (64-bit embedded ppc)

this is new I guess. Its like adding a new arch to OE. See around
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/024661.html
is roughly what can be helpful in getting ppc64 going

Thanks, will take a look at that.

- k

On Fri, Jul 15, 2011 at 2:10 PM, Kumar Gala <galak@...> wrote:

In my attempts to get an e500v2/gnuspe toolchain working I was able to get core-image-minimal working.  However when I try the 'meta-toolchain' I run into the following below.  I believe this is because of TARGET_OS being 'linux-gnuspe'.

Any ideas ?

- k

[kumar@right build-p2020]$ bitbake meta-toolchain

OE Build Configuration:
BB_VERSION        = "1.13.2"
TARGET_ARCH       = "powerpc"
TARGET_OS         = "linux-gnuspe"
MACHINE           = "p2020-ds"
DISTRO            = "poky"
DISTRO_VERSION    = "1.0+snapshot-20110715"
TARGET_FPU        = "spe"
meta
meta-yocto        = "master:068839698fe192d8846c0ed4db65861448e8e524"

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/powerpc-poky-linux-libc-for-gcc'

here is the problem. This should have been called
virtual/powerpc-poky-linux-gnuspe-libc-for-gcc

so TARGET_PREFIX is not being set correctly which means TARGET_SYS is
not being set correctly

and

TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' +
bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d,
1) == ('' or 'custom')]}"

so it should be ok if TARGET_OS is set

can you pastebin output of

bitbake -e meta-toolchain

somewhere

NOTE: Runtime target 'gcc-cross-canadian-powerpc' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
NOTE: Runtime target 'task-cross-canadian-powerpc' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
ERROR: Required build target 'meta-toolchain' has no buildable providers.
Missing or unbuildable dependency chain was: ['meta-toolchain', 'task-cross-canadian-powerpc', 'gcc-cross-canadian-powerpc', 'virtual/powerpc-poky-linux-libc-for-gcc']
ERROR: Command execution failed: Traceback (most recent call last):
 File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 102, in runAsyncCommand
   commandmethod(self.cmds_async, self, options)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/command.py", line 200, in buildTargets
   command.cooker.buildTargets(pkgs_to_build, task)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/cooker.py", line 996, in buildTargets
   taskdata.add_unresolved(localdata, self.status)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 534, in add_unresolved
   self.remove_buildtarget(targetid)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 491, in remove_buildtarget
   self.fail_fnid(fnid, missing_list)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in fail_fnid
   self.remove_runtarget(target, missing_list)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in remove_runtarget
   self.fail_fnid(fnid, missing_list)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 476, in fail_fnid
   self.remove_runtarget(target, missing_list)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 517, in remove_runtarget
   self.fail_fnid(fnid, missing_list)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 471, in fail_fnid
   self.remove_buildtarget(target, missing_list)
 File "/local/home/kumar/git/poky/bitbake/lib/bb/taskdata.py", line 501, in remove_buildtarget
   raise bb.providers.NoProvider(target)
NoProvider: meta-toolchain

This bug: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1177 only
occurs on my CentOS 5 boxes (not on my Fedora 13 box). I have
determined that this git patch
4b66ce472871618cfe4761861392b7f9c3c265b0 is causing the problem.
Reverting the patch fixes this.

Still looking at this more but I thought I would share this with
everyone and see if anyone has a more specific reason why this is
happening.

-M