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

[Khem Raj]

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.
> There are 110 .bb files that reference TARGET_ARCH

right. I am using MULTIMACH_ARCH (may be it should be called
TARGET_SUB_ARCH) to construct
all canonical names. Which should leave TARGET_ARCH unaffected at the same time
help us to have multiple toolchains co-exist.
I am trying a build where the HOST_SYS and TARGET_SYS will then use this var.
lets see where I end up.

>
> the last two lines of the grep read:
> xqt2/xqt2_20060509.bb:    if [ ${TARGET_ARCH} == "arm" ]; then
> xqt/xqt_0.0.9.bb:    if [ ${TARGET_ARCH} == "arm" ]; then
> so these are definitely not going to fly
>
> for some other of the 110 recipes the change is harmless (e.g. because they
> compare to "mips" in gcc-common.inc)
> for most others I cannot judge this, e.g. because the value is passed to
> configure.
>
> unrelated side note:
> while grepping I noticed the existence of dirs like linux-uml and linux-atm.
> These contain kernel recipes.
> Shouldn't these be in linux recipes dir? (or alternately shouldn't there be
> also things like linux-omap and linux-nios2).
>
> frans
>
>
>> If that doesn't help which I suspect it won't, my gut instinct is to add
>> a architecture specific directory under bin for the cross bits. This
>> could be as simple as changing bindir in cross.bbclass.
>>
>> > I don't know if that solves the binutils-cross problem[1], though.
>> >
>> > Koen
>> >
>> > [1] http://thread.gmane.org/gmane.comp.handhelds.openembedded/34685
>>
>> Is that libiberty.a file actually useful or could we just stop
>> binutils-cross installing it?
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>