[oe] [PATCH 0/4][RFC] Remove CROSS_DIR, install cross-packages into native sysroot

[Khem Raj]

On (23/07/10 10:30), Chris Larson wrote:
> On Fri, Jul 23, 2010 at 10:20 AM, Khem Raj <raj.khem at gmail.com> wrote:
> 
> > On Fri, Jul 23, 2010 at 2:18 AM, Frans Meulenbroeks
> > <fransmeulenbroeks at gmail.com> wrote:
> > > 2010/7/23 Richard Purdie <rpurdie at rpsys.net>
> > >
> > >> 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
-------------- next part --------------
diff --git a/classes/cross.bbclass b/classes/cross.bbclass
index 75b2abe..cadf245 100644
--- a/classes/cross.bbclass
+++ b/classes/cross.bbclass
@@ -8,7 +8,7 @@ EXCLUDE_FROM_WORLD = "1"
 # In order to keep TARGET_PREFIX decoupled from TARGET_SYS, let's force the
 # binary names to match the former, rather than relying on autoconf's implicit
 # prefixing based on the latter.
-EXTRA_OECONF_append = " --program-prefix=${TARGET_PREFIX}"
+EXTRA_OECONF_append = " --program-prefix=${MULTIMACH_TARGET_PREFIX}"
 
 # Save PACKAGE_ARCH before changing HOST_ARCH
 OLD_PACKAGE_ARCH := "${PACKAGE_ARCH}"
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 748abba..1564f10 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -135,6 +135,7 @@ PACKAGE_ARCHS = "all any noarch ${TARGET_ARCH} ${PACKAGE_EXTRA_ARCHS} ${MACHINE}
 MULTIMACH_ARCH = "${PACKAGE_ARCH}"
 MULTIMACH_TARGET_SYS = "${MULTIMACH_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
 MULTIMACH_HOST_SYS = "${MULTIMACH_ARCH}${HOST_VENDOR}-${HOST_OS}"
+MULTIMACH_TARGET_PREFIX = "${MULTIMACH_TARGET_SYS}-"
 BASEPKG_HOST_SYS = "${BASE_PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
 BASEPKG_TARGET_SYS = "${BASE_PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"