From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
Date: Fri, 30 Apr 2010 15:35:51 -0400 [thread overview]
Message-ID: <20100430193551.GD5713@denix.org> (raw)
In-Reply-To: <1272392294.3865.571.camel@trini-m4400>
On Tue, Apr 27, 2010 at 11:18:14AM -0700, Tom Rini wrote:
> On Mon, 2010-04-26 at 14:03 -0400, Denys Dmytriyenko wrote:
> > On Sat, Apr 24, 2010 at 11:51:09AM -0700, Tom Rini wrote:
> [snip]
> > > Right. I'm saying that SDKPATH should be more than /usr/local/${DISTRO}
> > > but /usr/local/${DISTRO}/${MACHINE} by default, toss a comment above
> > > about why (output is very MACHINE specific in certain cases) and maybe
> > > update the default TOOLCHAIN_OUTPUTNAME too.
> >
> > Ok, you asked for a comment, I'll give you two :)
> >
> > 1. In Arago I have a way to overwrite SDKPATH from the command line when
> > building a specific SDK/toolchain. So, I can do what you suggest, but...
> >
> > 2. My SDKs are currently not machine-specific, moreover, they don't have the
> > cross-compile tools in them (i.e. no toolchain part), as Arago uses external
> > CodeSourcery toolchain for that. The only cross-tools I have in my SDKs are
> > those, which are missing from CS - i.e. libtool, pkgconfig, opkg, qt4e-tools
> > etc. But I still build 2 versions of SDK - armv5te and armv7a.
>
> I'd make a very small wager that you're unknowningly wrong about #2 or a
> someone adding an RRECOMMENDS/RDEPENDS_mach somewhere (or using another
> machine you haven't tried yet) from machine specific stuff leaking in
> and being wrong :)
>
> It's not the gcc & co that you get from CodeSourcery or our -sdk recipes
> or whatever that makes this machine-specific but the conditional
> inclusion of some userland bits (be it "small" "regular" Linux stuff or
> "small" stuff for FPGAs or whatever on a particular ref board). Or even
> PACKAGE_ARCH=MACHINE stuff already being in there, again without you
> knowning (some of which can be rather easily pulled out with that
> removal hook you added).
In general, you are correct, but:
$ grep 'Architecture:' $SDK_PATH/$TARGET_SYS/usr/lib/opkg/status | uniq
armv7a
So, I'm being carefull and use the EXCLUDE removal hook extensively :)
--
Denys
prev parent reply other threads:[~2010-04-30 19:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-21 12:21 [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS Koen Kooi
2010-04-23 11:07 ` Koen Kooi
2010-04-23 18:07 ` Tom Rini
2010-04-23 18:22 ` Denys Dmytriyenko
2010-04-23 18:45 ` Koen Kooi
2010-04-23 18:55 ` Tom Rini
2010-04-23 20:29 ` Koen Kooi
2010-04-23 20:54 ` Denys Dmytriyenko
2010-04-23 21:43 ` Tom Rini
2010-04-24 17:07 ` Denys Dmytriyenko
2010-04-24 18:51 ` Tom Rini
2010-04-26 18:03 ` Denys Dmytriyenko
2010-04-27 18:18 ` Tom Rini
2010-04-30 19:35 ` Denys Dmytriyenko [this message]
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=20100430193551.GD5713@denix.org \
--to=denis@denix.org \
--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