On (23/07/10 10:30), Chris Larson wrote: > On Fri, Jul 23, 2010 at 10:20 AM, Khem Raj wrote: > > > On Fri, Jul 23, 2010 at 2:18 AM, Frans Meulenbroeks > > wrote: > > > 2010/7/23 Richard Purdie > > > > > >> On Fri, 2010-07-23 at 10:11 +0200, Koen Kooi wrote: > > >> > -----BEGIN PGP SIGNED MESSAGE----- > > >> > Hash: SHA1 > > >> > > > >> > On 23-07-10 10:02, Phil Blundell wrote: > > >> > > On Fri, 2010-07-23 at 09:25 +0200, Koen Kooi wrote: > > >> > >> There is a BIG problem with these patches, they break multimachine > > >> builds. > > >> > >> > > >> > >> The previous situation had: > > >> > >> > > >> > >> cross/armv7a-angstrom-foo/usr/bin/ > > >> > >> cross/armv5te-angstrom-foo/usr/bin/ > > >> > >> etc > > >> > >> > > >> > >> The new situation has: > > >> > >> > > >> > >> x86_64-linux/usr/bin > > >> > >> > > >> > >> So all the toolchains get dropped into the *same* directory, which > > >> > >> breaks horribly. > > >> > > > > >> > > Which are the actual binaries that collide? I would have thought > > that > > >> > > everything which gets installed into the cross bindir ought to be > > >> > > prefixed with TARGET_SYS (i.e. usr/bin/armv7a-angstrom-linux-gcc, > > etc). > > >> > > > >> > It's all 'arm-angstrom-foo', I was just about to make the suggestion > > to > > >> > change it to 'armv7a-angstrom-foo' :) > > >> > > >> I've just been talking to Koen about this. When building for armv7a, > > >> TARGET_ARCH which goes into TARGET_PREFIX and TARGET_SYS is "arm". > > >> > > >> I suspect if we change TARGET_ARCH to be armv7a, nasty things will > > >> happen but I could be wrong. > > >> > > > > > > I've been pondering if TARGET_ARCH should be the real arch (like armv7a) > > and > > > whether adjacent to that there should be a TARGET_ARCH_FAMILY or so. > > > > > > Changing TARGET_ARCH to armv7a without other changes definitely is going > > to > > > break things. > > > > > > maybe we should not change TARGET_ARCH but use FEED_ARCH to construct > > TARGET_SYS > > > Using a variable from packaging / rootfs creation as a field passed to > configure at build time strikes me as a terrible idea. we have MULTIMACH_* variables in bitbake.conf I have done this patch using them. I trying a meta-toolchain build lets see -Khem > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel