[meta-ti] u-boot compile failure

[Jack Mitchell]

On 16/10/12 14:37, Denys Dmytriyenko wrote:
> 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.

Bingo, that answered every question I had lingering - even including the 
one about building different native for different architectures that I 
resisted asking! ;)

Thanks Denys - I'll get there eventually!

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


-- 

   Jack Mitchell (jack at embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--