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
On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala ga...@kernel.crashing.org 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
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
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 ga...@kernel.crashing.org
wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler
working and seem to have build a native
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 Galaga...@kernel.crashing.org wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working
and seem to have build a native toolchain.
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 Galaga...@kernel.crashing.org
wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler
On Mon, Jul 18, 2011 at 11:01 AM, Kumar Gala ga...@kernel.crashing.org 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 Galaga...@kernel.crashing.org
wrote:
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 Galaga...@kernel.crashing.org
wrote:
I've been working on
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
On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala ga...@kernel.crashing.org 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:
On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala ga...@kernel.crashing.org
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 ga...@kernel.crashing.org wrote:
On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala ga...@kernel.crashing.org
wrote:
You can try -fno-use-linker-plugin as a workaround. Does
liblto_plugin.so exist on target
On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:
On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala ga...@kernel.crashing.org
wrote:
On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
On Mon, Jul 18, 2011 at 11:24 AM, Kumar Gala ga...@kernel.crashing.org
wrote:
You can try -fno-use-linker-plugin as
On Mon, Jul 18, 2011 at 1:04 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Jul 18, 2011, at 2:27 PM, Khem Raj wrote:
On Mon, Jul 18, 2011 at 12:22 PM, Kumar Gala ga...@kernel.crashing.org
wrote:
On Jul 18, 2011, at 1:37 PM, Khem Raj wrote:
On Mon, Jul 18, 2011 at 11:24 AM, Kumar
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 ga...@kernel.crashing.org
---
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 ga...@kernel.crashing.org
---
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
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
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 ga...@kernel.crashing.org
---
meta/recipes-connectivity/openssl/openssl.inc |3 +++
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
20 matches
Mail list logo
