Re: Poky SDK as an external toolchain

[Gary Thomas <gary@mlbassoc.com>]

On 2011-10-14 10:15, Richard Purdie wrote:
> On Fri, 2011-10-14 at 11:06 -0500, Mark Hatle wrote:
>> On 10/14/11 9:44 AM, Gary Thomas wrote:
>>> Premise: I'm happy with the toolchain that builds with Poky/Yocto
>>> Problem: I'm not happy rebuilding said toolchain all the time, nor
>>> having my customers have to rebuild it.
>>>
>>> Solution? I'd like to build the meta-toolchain and then be able to
>>> use that as an external toolchain for subsequent builds.  That way,
>>> I can create the tools and reuse them internally as well as pass
>>> them to my customers.
>>>
>>> How can I make this happen?  The last time I tried anything like
>>> this, I spent many days in the attempt only to find out that it
>>> was never going to work...
>>
>> We have a similar need for our commercial products.  We allow/enable our
>> customers to rebuild the toolchains (and use the results), but we only provide
>> official support for our binary versions.  There are simply too many variations
>> possible to try to support the toolchains in source format.  (Toolchains =
>> bintuils, gcc, stock eglibc and a stock uclibc configurations...)
>>
>> Our intention is simply to create custom recipes that extract our binaries and
>> use them instead of doing a by-source build.  If there is an easier way that
>> would be nice.  (And I agree, using the results of the meta-toolchain build is
>> the right approach for anything standard.)
>>
>> I'd suggest this get added as an enhancement request to the bugzilla.  We're
>> currently working on feature planning for 1.2 so this would be a good time to
>> add it into the bucket of possible work items.
>
> We already support external toolchains just fine. You can use a
> meta-toolchain as an external toolchain.

How do I do this?   I really don't want to deal with another toolchain [vendor]
like CSL.  As I said, I'm very happy with the toolchains that are being built,
I just want to reuse them.

>
> If you want to reuse the toolchain directly, we do have sstate and we
> need to fix issues it has. We know and acknowledge they exist, we just
> need to track down the problems and fix them. The more people who help
> with that the sooner it will get done.
>
> If anything goes into the bugzilla it should be examples of where sstate
> is failing. Most sstate bugs do get resolved failrly quickly.

My bug #1536 gives a very explicit failure case, including a script to
recreate it from scratch.  I've not heard anything about it except "later"

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------