On Mon, Nov 28, 2011 at 9:32 PM, McClintock Matthew-B29882
<b29...@freescale.com> wrote:
> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
> <richard.pur...@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 ? -- Julian -- Julian _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
