[OE-core] [PATCH v3] Introduce multiarch DISTRO_FEATURE

[Khem Raj]

On Mon, Nov 28, 2011 at 2:14 PM, Julian Pidancet
<julian.pidancet at gmail.com> wrote:
> On Mon, Nov 28, 2011 at 9:32 PM, McClintock Matthew-B29882
> <B29882 at freescale.com> wrote:
>> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>>> This is firmly in multilib territory as its not just libgcc but libc as
>>> well and so it goes on.
>>>
>>> One of the reasons I'm nervous of the patch you're replying to is that
>>> people are now going to try and cross the two and we'll end up with a
>>> mess :(.
>>>
>>> Trying to build just libgcc from the gcc tree is a nightmare and when we
>>> last tried it, caused no end of problems.
>>>
>>> What specific problem are you trying to solve?
>>
>> The specific issue I'm having is for our 64-bit part that still uses a
>> 32-bit u-boot. Not sure the best approach really is...
>>
>> I've tried utilizing multilib by adding the following to my u-boot
>> recipe, but it's just hacky...
>>
>> DEPENDS_e5500-64b_append = " lib32-gcc"
>> CC_e5500-64b = "powerpc-poky-linux-gcc -m32"
>>
>> I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
>> u-boot where we don't need libc. I'd rather just have a functional
>> 32bit/64bit compiler for our 64-bit target.
>>
>> Looking forward farther, I would like to have one toolchain
>> ("meta-toolchain") that can produce target code for multiple targets
>> also.
>>
>
> Does u-boot really need to compile against libgcc ? I'm just curious.
>
> Unfortunately I believe that producing one libgcc per bit format is a
> multilib use-case, not a bi-arch use-case.
>
> Richard, regarding your concerns about people mixing up bi-arch and
> multilib. Isn't there any way we could make these two things mutually
> exclusive ?

I think we should make it inclusive
ideally we should have bi-arch/tri-arch toolchain building multilib userspace.
in which case we have single compiler for multilib as well as archness