Poky SDK as an external toolchain

Poky SDK as an external toolchain

[Gary Thomas]

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...

Note: sstate is *not* the answer.  Not only is it HUGE (well over
1GB for a typical setup), but it doesn't work reliably - see
bug #1536

Ideas/hints?

Thanks

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

Re: Poky SDK as an external toolchain

[Richard Purdie]

On Fri, 2011-10-14 at 08:44 -0600, 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 used to have code for doing exactly what you describe. It was error
prone, buggy and a world of pain. I was very relived when we removed it.

We do have external toolchain support. You could use that as you would
for a toolchain shipped by CSL or similar.

> Note: sstate is *not* the answer.  Not only is it HUGE (well over
> 1GB for a typical setup), but it doesn't work reliably - see
> bug #1536

sstate is the answer and we need to actually make it work for your use
cases. We need to look at the problems you're having and find ways to
address them. I know it has issues but there isn't anything
fundamentally wrong with what its doing, we just need to get the issues
addressed. I'll happily do what I can to help that (and have been trying
to already) if the issues are known about. This is the first time anyone
has mentioed the 1GB size problem of the toolchain for example...

Cheers,

Richard

Re: Poky SDK as an external toolchain

[Mark Hatle]

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.

--Mark

> Note: sstate is *not* the answer.  Not only is it HUGE (well over
> 1GB for a typical setup), but it doesn't work reliably - see
> bug #1536
> 
> Ideas/hints?
> 
> Thanks
> 

Re: Poky SDK as an external toolchain

[Richard Purdie]

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.

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.

Cheers,

Richard

Re: Poky SDK as an external toolchain

[Mark Hatle]

On 10/14/11 11:15 AM, 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.

But we don't have a way to use OUR external toolchain directly as the toolchain
for building, avoiding building new ones right?

> 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.

This is one case where I think sstate is only the answer for those folks who
want to speed rebuilding.  But in the case where you've come up with a certified
set of binary components.. there needs to be a way to inject that in without the
weight of the sstate.  (Copy of all of the various stages of the install, build,
packaging..)

> If anything goes into the bugzilla it should be examples of where sstate
> is failing. Most sstate bugs do get resolved failrly quickly.

I think this is a different usecase then the sstate.  To me sstate allows the
use of a cache to speed up building.  This is a case where we want to use
something external (which happens to be built by the build system -- setting the
default format) to avoid performing any build operations.

--Mark

> Cheers,
> 
> Richard
> 

Re: Poky SDK as an external toolchain

[Khem Raj]

On Fri, Oct 14, 2011 at 9:06 AM, Mark Hatle <mark.hatle@windriver.com> 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.

i think making external toolchains pluggable is a good feature. We could work
towards getting it documented and any support needed in metadata. I
have come across many users
who would want to have such a set up.

>
> --Mark
>
>> Note: sstate is *not* the answer.  Not only is it HUGE (well over
>> 1GB for a typical setup), but it doesn't work reliably - see
>> bug #1536
>>
>> Ideas/hints?
>>
>> Thanks
>>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>

Re: Poky SDK as an external toolchain

[Gary Thomas]

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
------------------------------------------------------------

Re: Poky SDK as an external toolchain

[Tom Rini]

On Fri, Oct 14, 2011 at 12:01 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> 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.

What Richard is saying is that based on the recipe for CSL (which just
plugs the binary in and satisfies DEPENDS, etc) you can do the same
for one that comes out via the meta-toolchain recipe.  Provided that is,
the toolchain that comes out of meta-toolchain does what you want it to do.

See http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb
as an example

-- 
Tom

Re: Poky SDK as an external toolchain

[Gary Thomas]

On 2011-10-14 13:58, Tom Rini wrote:
> On Fri, Oct 14, 2011 at 12:01 PM, Gary Thomas<gary@mlbassoc.com>  wrote:
>> 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.
>
> What Richard is saying is that based on the recipe for CSL (which just
> plugs the binary in and satisfies DEPENDS, etc) you can do the same
> for one that comes out via the meta-toolchain recipe.  Provided that is,
> the toolchain that comes out of meta-toolchain does what you want it to do.
>
> See http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb
> as an example
>

Filed as enhancement bug: http://bugzilla.pokylinux.org/show_bug.cgi?id=1681

Note: I think this should be solveable with just a limited number of soft links
to the [well known] meta-toolchain install.

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

Re: Poky SDK as an external toolchain

[Richard Purdie]

On Fri, 2011-10-14 at 11:21 -0500, Mark Hatle wrote:
> On 10/14/11 11:15 AM, 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.
> 
> But we don't have a way to use OUR external toolchain directly as the toolchain
> for building, avoiding building new ones right?

We have a way of generically using external toolchains to replace our
internal self-built one. As Tom pointed out see:

http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/meta/external-csl-toolchain_2008q3-72.bb

and also the TCMODE variable.

> > 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.
> 
> This is one case where I think sstate is only the answer for those folks who
> want to speed rebuilding.  But in the case where you've come up with a certified
> set of binary components.. there needs to be a way to inject that in without the
> weight of the sstate.  (Copy of all of the various stages of the install, build,
> packaging..)

Agreed, although I'm hoping sstate can actually be used here generically
with a brute force of the sstate hash compatibility. The whole of the
checksum infrsatructure is configurable and customisable but we've not
seen people use it much, yet

> I think this is a different usecase then the sstate.  To me sstate allows the
> use of a cache to speed up building.  This is a case where we want to use
> something external (which happens to be built by the build system -- setting the
> default format) to avoid performing any build operations.

This is exactly what ASSUME_PROVIDED is for and how our external
toolchain support works. We can do this, people just don't chose to much
at the moment...

Cheers,

Richard