[yocto] examples / docs on utilizing an external toolchain

[Gary Thomas]

On 2011-08-04 09:06, Khem Raj wrote:
> On Thursday, August 04, 2011 08:58:59 AM Gary Thomas wrote:
>> On 2011-08-04 08:49, Richard Purdie wrote:
>>> On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote:
>>>> On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote:
>>>>> On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote:
>>>>>> On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote:
>>>>>>> On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote:
>>>>>>>> Bug submitted:
>>>>>>>>
>>>>>>>> http://bugzilla.pokylinux.org/show_bug.cgi?id=1323
>>>>>>>>
>>>>>>>> My question still stands even w/o it being in formal docs.
>>>>>>>
>>>>>>> FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core
>>>>>>> changes.
>>>>>>> I'd be interested to know where we've missed the references to
>>>>>>> it and
>>>>>>> get to get those references fixed.
>>>>>>
>>>>>> Ok, but how does one use TCMODE?  :)
>>>>>>
>>>>>> is there an example around anywhere?
>>>>>
>>>>> I'll explain on the condition that someone actually documents this
>>>>> ;-).
>>>>>
>>>>> TCMODE determines which of the files in
>>>>> meta/conf/distro/include/tcmode-* is used. It defaults to "default"
>>>>> and
>>>>> our default toolchain definition is in tcmode-default.inc.
>>>>>
>>>>> There is another example there which is "external-csl2008q3". As you
>>>>> can see from the tcmode-external-csl2008q3 file, it sets up the
>>>>> system to use an external toolchain instead.
>>>>>
>>>>> So you can define one of these files in your layer and then the
>>>>> system
>>>>> can select alternative toolchain configurations.
>>>>>
>>>>> Does that help? :)
>>>>>
>>>>> There is a similar TCLIBC variable which controls which libc is used
>>>>> (eglibc or uclibc).
>>>>
>>>> Yes that helps.  So it looks as if today there is not a means to point
>>>> to SDK prebuilt toolchain via this means.
>>>
>>> We have supported this in the past but it got messy and I'd really
>>> prefer people to use sstate for this.
>>
>> That would be great, if only it worked for this purpose.  Sadly, I've not
>> had much luck with sharing toolchains like this.
>>
>> Here's my problem - I have a number of different target platforms (MACHINE),
>> all of which are really the same ARM SoC (OMAP/3530==armv7a).  When I try
>> to share the sstate between them, the toolchain always rebuilds from
>> scratch.
>
> can you post bitbake -e of say gcc-cross gcc-runtime and eglibc
> for both machines ? We somehow need to figure what changes the signatures
>
>> A lot of other packages do seem to share state properly, e.g.
>> busybox built for these platforms uses sstate well, but not so with
>> toolchains.
>>
>> Is there any way for this to work?  I'd love to be able to hand my customers
>> a set of sstate files for the things they don't really need to rebuild and
>> the toolchains are a giant part of it.  If this should work and the current
>> failures a bug, I'll report it as such.
>>
>> Thanks

This turns out (in my case) to be a sensitivity to $DISTRO_FEATURES
One of my builds had slightly different value, but not such that it
actually changed any packages (it had an unused key).

I tried this with two machines, identical except in the name, with machineB
sharing state with machineB.  The only packages which had to be rebuilt were
the target specific ones, e.g. the machine kernel.

If I touch DISTRO_FEATURES in the build for machineB though, the number of
packages rebuilt skyrockets (list attached).

For now, I'll make sure that DISTRO_FEATURES is not something that my builds
touch.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pkgs
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20110804/356da8b1/attachment.ksh>