[meta-ti] u-boot compile failure

[Denys Dmytriyenko]

On Tue, Oct 16, 2012 at 02:16:14PM +0100, Jack Mitchell wrote:
> On 16/10/12 14:00, Denys Dmytriyenko wrote:
> >On Tue, Oct 16, 2012 at 09:22:57AM +0100, Jack Mitchell wrote:
> >>On 16/10/12 02:20, Tom Rini wrote:
> >>>On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml at communistcode.co.uk> wrote:
> >>>>It seems that u-boot is attempting to use GCC includes from my host system
> >>>>here. This surely isn't right is it?
> >>>There are host tools to build.  That said, from the log it looks like
> >>>you have been trying to build this a few times.  If you bitbake -c
> >>>clean u-boot do you still see the problem?
> >>>
> >>I get the error[1] after the -c clean.
> >>
> >>I think I know what it is, that I upgraded my host distro yesterday
> >>which pulled in a new GCC and the old GCC libraries are still in the
> >>path. However, bitbake shouldn't be going into the host system for
> >>includes should it? Shouldn't it use it's own compiled GCC and
> >>associated libraries to generate the u-boot tools rather than rely
> >>on whatever is present on my host system, or am I missing something?
> >>I'm pretty sure a reboot would sort it out but I didn't want to kill
> >>a failure case.
> >Jack,
> >
> >It's not u-boot that fails for you, it's u-boot-mkimage-native - it's a host
> >tool to generate u-boot images, so it runs on your host and hence is built
> >with your host compiler. OE/Yocto usually builds bunch of host tools and they
> >have the "-native" suffix in their names. Upgradig your host system w/o
> >switching profiles or changing paths is a common issue in such cases.
> >
> 
> Ok, so when a package is labelled -native it is not only native in
> architecture but linked to the specific host?

Yes, because that code is used locally on the same host and only for the 
build. You don't ship that code, as it doesn't even get packaged anywhere - 
it gets populated in the sysroots and used for the builds.

For something that you need to distribute/ship, that needs to run on a host, 
there's SDK with Canadian cross, where you get a complete separation and host 
binaries that are not linked to a specific host. Moreover, you can target 
32bit x86 SDK host, while building it on a 64bit-only x86 build host. Those 
are marked with "-nativesdk" suffix instead.

> This is just out of interest since I was unaware of the level of
> host intrusion on a build.

-- 
Denys