From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "David Nyström" <david.c.nystrom@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"
Date: Mon, 13 Jan 2014 12:41:55 +0000 [thread overview]
Message-ID: <1389616915.14987.4.camel@ted> (raw)
In-Reply-To: <52D3DDFB.8080803@gmail.com>
On Mon, 2014-01-13 at 13:37 +0100, David Nyström wrote:
> Just to clarify bug 5354:
> If I understand the bug correctly, this would arise when first building
> the nativesdk tarball on a MACHINE with ABI linux,
> and then building the nativesdk for another MACHINE(with the same the
> same TUNE) after altering ABIEXTENSION to linux-gnuspe ?
>
> If I understand bug 5354 correctly, perhaps the tmp/sdk/tarball.here
> can be ABI specific ?
The idea behind the changes to cross-canadian were to have just a single
gcc/binutils which generated all of the appropriate targets for a given
architecture.
I understood this to be possible but it looks like we may need to tweak
things a bit.
> i.e. a generic rule that all nativesdk builds are invalidated if the
> ABI changes. I guess that would mean:
> cross-canadian.bbclass: TARGET_ARCH[vardeps] += "ABIEXTENSION"
> + Adding ABIEXTENSION to the nativesdk tarball name.
>
> PPC '=mabi=spe' seems to be one-way compatible, I could not get the
> non-SPE configured compiler
> to work with the SPE sysroot.
> Another possible solution would be to always configure the compiler to
> SPE, and use compile time flags in the
> environment file to do the selects. + symlinks for the compiler paths.
Can we configure the compiler to include SPE support without changing
the paths/OS string?
> However, even if we fix it this way for powerpc, we will still have
> this issue with thumb f.ex.
Keep in mind the target sysroot still varies for each different target.
The thing we're trying to keep in common is the gcc/bintuils and only
have one copy for each target architecture. Is that possible in this
case if we somehow enable SPE support in gcc-cross-canadian?
Cheers,
Richard
next prev parent reply other threads:[~2014-01-13 12:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 14:48 [PATCH] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe" David Nyström
2014-01-10 15:15 ` Richard Purdie
2014-01-13 12:37 ` David Nyström
2014-01-13 12:41 ` Richard Purdie [this message]
2014-01-14 13:23 ` David Nyström
2014-01-17 14:43 ` alexandru.sardan
2014-01-18 11:20 ` Richard Purdie
2014-01-21 17:39 ` alexandru.sardan
2014-01-21 17:43 ` Richard Purdie
2014-01-23 18:22 ` alexandru.sardan
2014-01-24 15:37 ` Richard Purdie
2014-01-24 20:56 ` Phil Blundell
2014-01-28 14:03 ` alexandru.sardan
2014-01-29 11:38 ` Richard Purdie
2014-01-31 17:53 ` alexandru.sardan
2014-01-31 18:07 ` Richard Purdie
2014-01-31 18:17 ` alexandru.sardan
2014-02-11 10:07 ` David Nyström
2014-02-26 18:29 ` alexandru.sardan
2014-02-26 22:37 ` David Nyström
2014-02-27 12:21 ` alexandru.sardan
2014-01-21 17:59 ` Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1389616915.14987.4.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=david.c.nystrom@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.