[OE-core] LE and BE build for the same machine in Yocto

[Zhenhua Luo]

Hi Richard and Khem, 

Thanks for your comments. 

I have tried to build the LE u-boot for BE target in Yocto, the u-boot can be built successfully, I only need to pass "-mlittle-endian" for cross gcc and pass " -EL" for cross ld. 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Khem Raj [mailto:raj.khem at gmail.com]
> Sent: Friday, March 25, 2016 11:44 PM
> To: Richard Purdie <richard.purdie at linuxfoundation.org>
> Cc: Zhenhua Luo <zhenhua.luo at nxp.com>; openembedded-
> core at lists.openembedded.org
> Subject: Re: [OE-core] LE and BE build for the same machine in Yocto
> 
> 
> > On Mar 25, 2016, at 1:26 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> >
> > On Fri, 2016-03-25 at 06:07 +0000, Zhenhua Luo wrote:
> >> If the multilib feature is enabled in Yocto, two cross-compile gcc
> >> binaries will be generated to do both 32b and 64b build for the same
> >> machine.  Currently we have requirement to build LE u-boot and BE
> >> kernel/rootfs for the same machine, may I know if there is similar
> >> multilib mechanism in Yocto to support BE and LE build for the same
> >> machine?
> >
> > If u-boot doesn't need any support libs, the existing compiler can
> > likely cope with that. If you need libgcc, then you will need multilib.
> >
> > I'd like to get to a point where we can support this using multilib
> > however it might not all work correctly today. It would be interesting
> > to try it! The intent is to get to the point where it would work but
> > its not currently a priority as not many people have been asking for
> > it.
> >
> 
> Do you mean having BE/LE as a multilib option ? that might be a possibility and
> would probably make sense for this kind of limited scenario.
> 
> u-boot, kernel, are standalone apps, but some of them do need gcc runtime at
> various stages, some need startup files some need libgcc as well. Good thing is
> they won’t require libgcc_s but static libgcc, which can come from gcc-cross
> area and we don’t have to worry about packaging it for target. I wonder if we
> could tool the multilib configuration of cross-gcc separately from the rootfs
> 
> however, that might work for startup files since they are only needed during
> build and are not packaged into target package like libgcc is.
> 
> If we can limit ourselves to startup files and static libgcc then a solution could
> become possible.