From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: introducing a new architecture/machine; policy ? (and a question)
Date: Wed, 23 Jun 2010 10:15:24 -0700 [thread overview]
Message-ID: <20100623171524.GA5535@gmail.com> (raw)
In-Reply-To: <AANLkTimwSjUiEgwAU-l66u9Da5ckM4p2yD4naQq3g_ZZ@mail.gmail.com>
On (23/06/10 11:54), Frans Meulenbroeks wrote:
> 2010/6/23 Graeme Gregory <dp@xora.org.uk>:
> >> >> Also I don't feel empowered to make changes in distribution
> >> >> specific files.
> >
> > Why not, chances are Angstrom maintainers would be quite happy for you
> > to patch angstrom*.conf if you ask us.
> >
> > Graeme
>
> distribution != angstrom
> There are more distributions out there.
>
> The root cause of the problem is that a distro can specify a version
> of a tool (let's take gcc as an example) that is not supported by a
> specific hardware architecture.
> I'd say what we really need is a way to allow a processor architecture
> to specify which versions of binutls and gcc and friends are supported
> for that hw architecture.
> Mind you I talk about processor architectures, not boards.
> (actually I guess this extends to every package that contains assembly
> files or inline assembly)
>
> The problem became more visible with nios2 as this is an architecture
> that is not (yet) supported by gcc. Patches for now exist only for
> 4.1.2.
>
some architectures may not support particular version of say gcc but
still if that architecture is supported by a given distro then it should
define the required version of say gcc in distro.conf with override
for instance check conf/distro/include/sane-toolchain.inc which is serving
a few distributions overrides default compiler versions for AVR32
you need to do something same for nios2
Thanks
-Khem
> Frans.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
next prev parent reply other threads:[~2010-06-23 17:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-20 9:58 introducing a new architecture/machine; policy ? (and a question) Frans Meulenbroeks
2010-06-20 10:10 ` Frans Meulenbroeks
2010-06-20 12:35 ` Koen Kooi
2010-06-20 15:38 ` Frans Meulenbroeks
2010-06-23 8:53 ` Frans Meulenbroeks
2010-06-23 9:24 ` Koen Kooi
2010-06-23 9:36 ` Graeme Gregory
2010-06-23 9:54 ` Frans Meulenbroeks
2010-06-23 10:03 ` Graeme Gregory
2010-06-23 10:07 ` Philip Balister
2010-06-23 10:32 ` Koen Kooi
2010-06-23 11:16 ` Frans Meulenbroeks
2010-06-23 17:19 ` Khem Raj
2010-06-23 19:55 ` Frans Meulenbroeks
2010-06-23 22:20 ` Khem Raj
2010-06-23 17:15 ` Khem Raj [this message]
2010-06-23 17:18 ` Tom Rini
2010-06-23 10:09 ` Frans Meulenbroeks
2010-06-23 10:30 ` Koen Kooi
2010-06-23 17:23 ` Khem Raj
2010-06-23 20:04 ` Frans Meulenbroeks
2010-06-23 21:55 ` Adrian Alonso
2010-06-23 22:16 ` Khem Raj
2010-06-23 22:26 ` Khem Raj
2010-06-24 9:27 ` Koen Kooi
2010-06-24 11:23 ` Frans Meulenbroeks
2010-06-24 15:10 ` Khem Raj
2010-06-20 22: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=20100623171524.GA5535@gmail.com \
--to=raj.khem@gmail.com \
--cc=openembedded-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox