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
compil
On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala 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 err
On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala 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 ge
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 o
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
> > wrote:
> >> I've been working on trying to get an e500v2 (linux-gnuspe) compiler
> >> working and seem to have build a native toolchain. How
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 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
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
>>> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler
working a
On Mon, Jul 18, 2011 at 11:01 AM, 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
wrote:
> I've been working on t
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
wrote:
> I've been working on t
> 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/po
On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala 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 t
On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala
> 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
>>
On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala wrote:
>
> On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
>
>> On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala
>> wrote:
You can try -fno-use-linker-plugin as a workaround. Does
liblto_plugin.so exist on target rfs ?
it might be
On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala
> wrote:
>>
>> On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
>>
>>> On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala
>>> wrote:
> You can try -fno-use-linker-plugin as a workaround. Does
>
On Mon, Jul 18, 2011 at 1:04 PM, Kumar Gala wrote:
>
> On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:
>
>> On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala
>> wrote:
>>>
>>> On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
>>>
On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala
wrote:
>> You
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-boun...@yoctoproject.o
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
__
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
---
meta/recipes-devtools/gcc/gcc-4.6.inc|
Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
we build native toolchains. So we can utilize TARGET_FPU being set to
"spe" to determine if we should enable the gnuspe ABI.
Signed-off-by: Kumar Gala
---
meta/conf/distro/include/tclibc-eglibc.inc |2 +-
meta/conf/d
Signed-off-by: Kumar Gala
---
meta/conf/machine/include/tune-ppce500v2.inc |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc
diff --git a/meta/conf/machine/include/tune-ppce500v2.inc
b/meta/conf/machine/include/tune-p
If trying to build for an e500v2 target openssl will fail to build since
the configure script didn't know how to handle a 'gnuspe' target.
Signed-off-by: Kumar Gala
---
meta/recipes-connectivity/openssl/openssl.inc |3 +++
.../recipes-connectivity/openssl/openssl_0.9.8r.bb |2 +-
2
For a PPC target flac will try to build with altivec optimizations.
Altivec and SPE are mutually exclusive options. Between flac's
configure choices and the ppce500v2 tune file options we'd end up with
a compile invocation with the following arguments:
-mabi=spe -mspe -mabi=altivec -maltivec
Whi
On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala wrote:
> 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
On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala wrote:
> Signed-off-by: Kumar Gala
> ---
> meta/conf/machine/include/tune-ppce500v2.inc | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
> create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc
>
> diff --git a/meta/conf/mach
On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala wrote:
> 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
On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala wrote:
> Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
> we build native toolchains. So we can utilize TARGET_FPU being set to
> "spe" to determine if we should enable the gnuspe ABI.
>
> Signed-off-by: Kumar Gala
> ---
>
Signed-off-by: Kumar Gala
---
meta/conf/machine/include/tune-ppce500mc.inc |4
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce500mc.inc
diff --git a/meta/conf/machine/include/tune-ppce500mc.inc
b/meta/conf/machine/include/tune-pp
On Jul 19, 2011, at 1:01 AM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala
> wrote:
>> Signed-off-by: Kumar Gala
>> ---
>> meta/conf/machine/include/tune-ppce500v2.inc |5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>> create mode 100644 meta/conf/machine/i
On Jul 19, 2011, at 1:08 AM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala
> wrote:
>> Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
>> we build native toolchains. So we can utilize TARGET_FPU being set to
>> "spe" to determine if we should enable
On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala
> wrote:
>> 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 con
30 matches
Mail list logo
