Where did my preferred version go?

Where did my preferred version go?

[Gary Thomas]

I have a number of platforms which [for whatever reason]
need older versions of GCC.  I've been supporting this by
keeping the older code around in my own layers - I need
4.7.x for some targets, even 4.6.x for others.

With the changes in the latest master (post 1.6/daisy), I
am no longer able to build those older compilers :-(  First
I had to fix up some core changes to just get the recipes to
even parse (bb.utils.contains), but now I get a slew of errors
like these:

   NOTE: preferred version 4.7% of libgcc-initial not available (for item libgcc-initial)
   NOTE: versions of libgcc-initial available: 4.8.2 4.9.0

I looked at the old recipes and they don't provide these
packages which make them unsuitable.

I know I should move these targets to the newer GCC, but at
this moment there simply are not the resources to do so, but
we still want to benefit from other improvements in OE-core
(and Poky/Yocto).

How can I move forward?  Is there some way to retrofit the
older compilers into the new [required] structures?  Perhaps
I could use the older compilers as external tool chain, but
the last time I tried to use this (in place of the internal,
build in place) tools, I could never make things happy :-(

Any suggestions more than welcome, thanks

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

Re: Where did my preferred version go?

[Paul Barker]

On 14 May 2014 19:06, Gary Thomas <gary@mlbassoc.com> wrote:
> I have a number of platforms which [for whatever reason]
> need older versions of GCC.  I've been supporting this by
> keeping the older code around in my own layers - I need
> 4.7.x for some targets, even 4.6.x for others.
>

You're probably better off having these platforms built off an older
branch of OE.

I run multiple 'projects' (for want of a better term), one on dylan as
it needs a 3.2 series kernel, two on daisy and one on master. That is
a lot less painful than trying to shoehorn everything onto the master
branch.

Hope this helps,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: Where did my preferred version go?

[Richard Purdie]

On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
> I have a number of platforms which [for whatever reason]
> need older versions of GCC.  I've been supporting this by
> keeping the older code around in my own layers - I need
> 4.7.x for some targets, even 4.6.x for others.
> 
> With the changes in the latest master (post 1.6/daisy), I
> am no longer able to build those older compilers :-(  First
> I had to fix up some core changes to just get the recipes to
> even parse (bb.utils.contains), but now I get a slew of errors
> like these:
> 
>    NOTE: preferred version 4.7% of libgcc-initial not available (for item libgcc-initial)
>    NOTE: versions of libgcc-initial available: 4.8.2 4.9.0
> 
> I looked at the old recipes and they don't provide these
> packages which make them unsuitable.
> 
> I know I should move these targets to the newer GCC, but at
> this moment there simply are not the resources to do so, but
> we still want to benefit from other improvements in OE-core
> (and Poky/Yocto).
> 
> How can I move forward?  Is there some way to retrofit the
> older compilers into the new [required] structures?  Perhaps
> I could use the older compilers as external tool chain, but
> the last time I tried to use this (in place of the internal,
> build in place) tools, I could never make things happy :-(
> 
> Any suggestions more than welcome, thanks

How are you doing this? Have you a completely separate set of gcc
recipes including the include files or is this using the current include
files. You basically have two options:

a) Apply the changes that were made in master gcc to the 4.7 recipes,
you can then probably share includes.

b) Use a separate set of 4.7 files and "undo" some of the changes in
master using creative variable names. E.g., libgcc-initial was added:

recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
recipes-core/eglibc/eglibc.inc:DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers virtual/${TARGET_PREFIX}libc-initial"

so you could do a:

DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
DEPENDS_remove_pn-eglibc - "libgcc-initial"

Thinking a bit more, the issue that is going to hit you hard are the -PN
additions to the cross recipe changes (and their change in arch). My
strong recommendation is therefore a) and then replaying the gcc changes
made in master against the 4.7 version. These were:

http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc

there are about 10 or so changes there you'd need to check in your 4.7
recipes (since the 25th April) but nothing particularly difficult.

Cheers,

Richard

Re: Where did my preferred version go?

[Gary Thomas]

On 2014-05-15 14:53, Richard Purdie wrote:
> On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
>> I have a number of platforms which [for whatever reason]
>> need older versions of GCC.  I've been supporting this by
>> keeping the older code around in my own layers - I need
>> 4.7.x for some targets, even 4.6.x for others.
>>
>> With the changes in the latest master (post 1.6/daisy), I
>> am no longer able to build those older compilers :-(  First
>> I had to fix up some core changes to just get the recipes to
>> even parse (bb.utils.contains), but now I get a slew of errors
>> like these:
>>
>>     NOTE: preferred version 4.7% of libgcc-initial not available (for item libgcc-initial)
>>     NOTE: versions of libgcc-initial available: 4.8.2 4.9.0
>>
>> I looked at the old recipes and they don't provide these
>> packages which make them unsuitable.
>>
>> I know I should move these targets to the newer GCC, but at
>> this moment there simply are not the resources to do so, but
>> we still want to benefit from other improvements in OE-core
>> (and Poky/Yocto).
>>
>> How can I move forward?  Is there some way to retrofit the
>> older compilers into the new [required] structures?  Perhaps
>> I could use the older compilers as external tool chain, but
>> the last time I tried to use this (in place of the internal,
>> build in place) tools, I could never make things happy :-(
>>
>> Any suggestions more than welcome, thanks
>
> How are you doing this? Have you a completely separate set of gcc
> recipes including the include files or is this using the current include
> files. You basically have two options:

I made a complete copy of recipes-devtools/gcc before the original 4.8
recipes were added.

>
> a) Apply the changes that were made in master gcc to the 4.7 recipes,
> you can then probably share includes.
>
> b) Use a separate set of 4.7 files and "undo" some of the changes in
> master using creative variable names. E.g., libgcc-initial was added:
>
> recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
> recipes-core/eglibc/eglibc.inc:DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers virtual/${TARGET_PREFIX}libc-initial"
>
> so you could do a:
>
> DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
> DEPENDS_remove_pn-eglibc - "libgcc-initial"
>
> Thinking a bit more, the issue that is going to hit you hard are the -PN
> additions to the cross recipe changes (and their change in arch). My
> strong recommendation is therefore a) and then replaying the gcc changes
> made in master against the 4.7 version. These were:
>
> http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
>
> there are about 10 or so changes there you'd need to check in your 4.7
> recipes (since the 25th April) but nothing particularly difficult.

Thanks for these pointers.  I've given them a quick look and indeed
they look manageable, so I'll probably give them a go.

Do you know if anyone has ever [successfully!] used an existing
Poky/Yocto toolchain via the EXTERNAL_TOOLCHAIN method, like is
done by the meta-sourcery layers/tools?  I would think that would
be my safest bet - capture a working toolchain (I use both 4.6.3
and 4.7.2) and then enable the external support with the appropriate
toolchain/version (captured and managed out of band) for the targets
that need them.  How hard might this be?

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

Re: Where did my preferred version go?

[Paul Eggleton]

Hi Gary,

On Friday 16 May 2014 04:50:47 Gary Thomas wrote:
> On 2014-05-15 14:53, Richard Purdie wrote:
> > On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
> >> I have a number of platforms which [for whatever reason]
> >> need older versions of GCC.  I've been supporting this by
> >> keeping the older code around in my own layers - I need
> >> 4.7.x for some targets, even 4.6.x for others.
> >> 
> >> With the changes in the latest master (post 1.6/daisy), I
> >> am no longer able to build those older compilers :-(  First
> >> I had to fix up some core changes to just get the recipes to
> >> even parse (bb.utils.contains), but now I get a slew of errors
> >> 
> >> like these:
> >>     NOTE: preferred version 4.7% of libgcc-initial not available (for
> >>     item libgcc-initial) NOTE: versions of libgcc-initial available:
> >>     4.8.2 4.9.0
> >> 
> >> I looked at the old recipes and they don't provide these
> >> packages which make them unsuitable.
> >> 
> >> I know I should move these targets to the newer GCC, but at
> >> this moment there simply are not the resources to do so, but
> >> we still want to benefit from other improvements in OE-core
> >> (and Poky/Yocto).
> >> 
> >> How can I move forward?  Is there some way to retrofit the
> >> older compilers into the new [required] structures?  Perhaps
> >> I could use the older compilers as external tool chain, but
> >> the last time I tried to use this (in place of the internal,
> >> build in place) tools, I could never make things happy :-(
> >> 
> >> Any suggestions more than welcome, thanks
> > 
> > How are you doing this? Have you a completely separate set of gcc
> > recipes including the include files or is this using the current include
> 
> > files. You basically have two options:
> I made a complete copy of recipes-devtools/gcc before the original 4.8
> recipes were added.
> 
> > a) Apply the changes that were made in master gcc to the 4.7 recipes,
> > you can then probably share includes.
> > 
> > b) Use a separate set of 4.7 files and "undo" some of the changes in
> > master using creative variable names. E.g., libgcc-initial was added:
> > 
> > recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers
> > virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
> > recipes-core/eglibc/eglibc.inc:DEPENDS =
> > "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers
> > virtual/${TARGET_PREFIX}libc-initial"
> > 
> > so you could do a:
> > 
> > DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
> > DEPENDS_remove_pn-eglibc - "libgcc-initial"
> > 
> > Thinking a bit more, the issue that is going to hit you hard are the -PN
> > additions to the cross recipe changes (and their change in arch). My
> > strong recommendation is therefore a) and then replaying the gcc changes
> > made in master against the 4.7 version. These were:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
> > 
> > there are about 10 or so changes there you'd need to check in your 4.7
> > recipes (since the 25th April) but nothing particularly difficult.
> 
> Thanks for these pointers.  I've given them a quick look and indeed
> they look manageable, so I'll probably give them a go.
> 
> Do you know if anyone has ever [successfully!] used an existing
> Poky/Yocto toolchain via the EXTERNAL_TOOLCHAIN method, like is
> done by the meta-sourcery layers/tools?  I would think that would
> be my safest bet - capture a working toolchain (I use both 4.6.3
> and 4.7.2) and then enable the external support with the appropriate
> toolchain/version (captured and managed out of band) for the targets
> that need them.  How hard might this be?

We don't support this usage at the moment in OE; if you use the OE toolchain 
we recommend you let the system build it, and it will then be restored from 
shared state for subsequent builds. I searched around for discussion on this 
and coincidentally I turned up a thread you were on a few years ago:

  http://comments.gmane.org/gmane.linux.embedded.poky/7049

There was some discussion at the OEDAM meeting recently about trying to bring 
this back, but I'm pretty sure Richard is keen to avoid going down that path 
for the same reasons we've been avoiding it so far.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Where did my preferred version go?

[Gary Thomas]

On 2014-05-16 05:16, Paul Eggleton wrote:
> Hi Gary,
>
> On Friday 16 May 2014 04:50:47 Gary Thomas wrote:
>> On 2014-05-15 14:53, Richard Purdie wrote:
>>> On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
>>>> I have a number of platforms which [for whatever reason]
>>>> need older versions of GCC.  I've been supporting this by
>>>> keeping the older code around in my own layers - I need
>>>> 4.7.x for some targets, even 4.6.x for others.
>>>>
>>>> With the changes in the latest master (post 1.6/daisy), I
>>>> am no longer able to build those older compilers :-(  First
>>>> I had to fix up some core changes to just get the recipes to
>>>> even parse (bb.utils.contains), but now I get a slew of errors
>>>>
>>>> like these:
>>>>      NOTE: preferred version 4.7% of libgcc-initial not available (for
>>>>      item libgcc-initial) NOTE: versions of libgcc-initial available:
>>>>      4.8.2 4.9.0
>>>>
>>>> I looked at the old recipes and they don't provide these
>>>> packages which make them unsuitable.
>>>>
>>>> I know I should move these targets to the newer GCC, but at
>>>> this moment there simply are not the resources to do so, but
>>>> we still want to benefit from other improvements in OE-core
>>>> (and Poky/Yocto).
>>>>
>>>> How can I move forward?  Is there some way to retrofit the
>>>> older compilers into the new [required] structures?  Perhaps
>>>> I could use the older compilers as external tool chain, but
>>>> the last time I tried to use this (in place of the internal,
>>>> build in place) tools, I could never make things happy :-(
>>>>
>>>> Any suggestions more than welcome, thanks
>>>
>>> How are you doing this? Have you a completely separate set of gcc
>>> recipes including the include files or is this using the current include
>>
>>> files. You basically have two options:
>> I made a complete copy of recipes-devtools/gcc before the original 4.8
>> recipes were added.
>>
>>> a) Apply the changes that were made in master gcc to the 4.7 recipes,
>>> you can then probably share includes.
>>>
>>> b) Use a separate set of 4.7 files and "undo" some of the changes in
>>> master using creative variable names. E.g., libgcc-initial was added:
>>>
>>> recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers
>>> virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
>>> recipes-core/eglibc/eglibc.inc:DEPENDS =
>>> "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers
>>> virtual/${TARGET_PREFIX}libc-initial"
>>>
>>> so you could do a:
>>>
>>> DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
>>> DEPENDS_remove_pn-eglibc - "libgcc-initial"
>>>
>>> Thinking a bit more, the issue that is going to hit you hard are the -PN
>>> additions to the cross recipe changes (and their change in arch). My
>>> strong recommendation is therefore a) and then replaying the gcc changes
>>> made in master against the 4.7 version. These were:
>>>
>>> http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
>>>
>>> there are about 10 or so changes there you'd need to check in your 4.7
>>> recipes (since the 25th April) but nothing particularly difficult.
>>
>> Thanks for these pointers.  I've given them a quick look and indeed
>> they look manageable, so I'll probably give them a go.
>>
>> Do you know if anyone has ever [successfully!] used an existing
>> Poky/Yocto toolchain via the EXTERNAL_TOOLCHAIN method, like is
>> done by the meta-sourcery layers/tools?  I would think that would
>> be my safest bet - capture a working toolchain (I use both 4.6.3
>> and 4.7.2) and then enable the external support with the appropriate
>> toolchain/version (captured and managed out of band) for the targets
>> that need them.  How hard might this be?
>
> We don't support this usage at the moment in OE; if you use the OE toolchain
> we recommend you let the system build it, and it will then be restored from
> shared state for subsequent builds. I searched around for discussion on this
> and coincidentally I turned up a thread you were on a few years ago:
>
>    http://comments.gmane.org/gmane.linux.embedded.poky/7049
>
> There was some discussion at the OEDAM meeting recently about trying to bring
> this back, but I'm pretty sure Richard is keen to avoid going down that path
> for the same reasons we've been avoiding it so far.

I looked back through this thread and the enhancement bug I filed
(which for everyone but Richard seemed to be the way to go).  The
result was to reuse sstate, but I don't see how that can solve the
problem I have today.  How can I possibly create sstate cache files
for my old GCC/4.6.3 toolchain and allow them to be used with the
latest builds?

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

Re: Where did my preferred version go?

[Paul Eggleton]

On Friday 16 May 2014 05:31:41 Gary Thomas wrote:
> On 2014-05-16 05:16, Paul Eggleton wrote:
> > On Friday 16 May 2014 04:50:47 Gary Thomas wrote:
> >> On 2014-05-15 14:53, Richard Purdie wrote:
> >>> On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
> >>>> I have a number of platforms which [for whatever reason]
> >>>> need older versions of GCC.  I've been supporting this by
> >>>> keeping the older code around in my own layers - I need
> >>>> 4.7.x for some targets, even 4.6.x for others.
> >>>> 
> >>>> With the changes in the latest master (post 1.6/daisy), I
> >>>> am no longer able to build those older compilers :-(  First
> >>>> I had to fix up some core changes to just get the recipes to
> >>>> even parse (bb.utils.contains), but now I get a slew of errors
> >>>> 
> >>>> like these:
> >>>>      NOTE: preferred version 4.7% of libgcc-initial not available (for
> >>>>      item libgcc-initial) NOTE: versions of libgcc-initial available:
> >>>>      4.8.2 4.9.0
> >>>> 
> >>>> I looked at the old recipes and they don't provide these
> >>>> packages which make them unsuitable.
> >>>> 
> >>>> I know I should move these targets to the newer GCC, but at
> >>>> this moment there simply are not the resources to do so, but
> >>>> we still want to benefit from other improvements in OE-core
> >>>> (and Poky/Yocto).
> >>>> 
> >>>> How can I move forward?  Is there some way to retrofit the
> >>>> older compilers into the new [required] structures?  Perhaps
> >>>> I could use the older compilers as external tool chain, but
> >>>> the last time I tried to use this (in place of the internal,
> >>>> build in place) tools, I could never make things happy :-(
> >>>> 
> >>>> Any suggestions more than welcome, thanks
> >>> 
> >>> How are you doing this? Have you a completely separate set of gcc
> >>> recipes including the include files or is this using the current include
> >> 
> >>> files. You basically have two options:
> >> I made a complete copy of recipes-devtools/gcc before the original 4.8
> >> recipes were added.
> >> 
> >>> a) Apply the changes that were made in master gcc to the 4.7 recipes,
> >>> you can then probably share includes.
> >>> 
> >>> b) Use a separate set of 4.7 files and "undo" some of the changes in
> >>> master using creative variable names. E.g., libgcc-initial was added:
> >>> 
> >>> recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers
> >>> virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
> >>> recipes-core/eglibc/eglibc.inc:DEPENDS =
> >>> "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers
> >>> virtual/${TARGET_PREFIX}libc-initial"
> >>> 
> >>> so you could do a:
> >>> 
> >>> DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
> >>> DEPENDS_remove_pn-eglibc - "libgcc-initial"
> >>> 
> >>> Thinking a bit more, the issue that is going to hit you hard are the -PN
> >>> additions to the cross recipe changes (and their change in arch). My
> >>> strong recommendation is therefore a) and then replaying the gcc changes
> >>> made in master against the 4.7 version. These were:
> >>> 
> >>> http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
> >>> 
> >>> there are about 10 or so changes there you'd need to check in your 4.7
> >>> recipes (since the 25th April) but nothing particularly difficult.
> >> 
> >> Thanks for these pointers.  I've given them a quick look and indeed
> >> they look manageable, so I'll probably give them a go.
> >> 
> >> Do you know if anyone has ever [successfully!] used an existing
> >> Poky/Yocto toolchain via the EXTERNAL_TOOLCHAIN method, like is
> >> done by the meta-sourcery layers/tools?  I would think that would
> >> be my safest bet - capture a working toolchain (I use both 4.6.3
> >> and 4.7.2) and then enable the external support with the appropriate
> >> toolchain/version (captured and managed out of band) for the targets
> >> that need them.  How hard might this be?
> > 
> > We don't support this usage at the moment in OE; if you use the OE
> > toolchain we recommend you let the system build it, and it will then be
> > restored from shared state for subsequent builds. I searched around for
> > discussion on this> 
> > and coincidentally I turned up a thread you were on a few years ago:
> >    http://comments.gmane.org/gmane.linux.embedded.poky/7049
> > 
> > There was some discussion at the OEDAM meeting recently about trying to
> > bring this back, but I'm pretty sure Richard is keen to avoid going down
> > that path for the same reasons we've been avoiding it so far.
> 
> I looked back through this thread and the enhancement bug I filed
> (which for everyone but Richard seemed to be the way to go).  The
> result was to reuse sstate, but I don't see how that can solve the
> problem I have today.  How can I possibly create sstate cache files
> for my old GCC/4.6.3 toolchain and allow them to be used with the
> latest builds?

Well, it's true that sstate won't help you solve that problem since the recipe 
still needs to be buildable (i.e. all dependencies need to be satisfied); 
sstate is rather the answer to "I want an external toolchain to avoid having 
to build the toolchain on every new build" which is a different problem. 
However, the recipes for an external toolchain must satisfy the exact same 
dependencies, so maintaining your old toolchain recipes isn't a whole lot 
different than an external toolchain at least in that respect, although you 
might argue that that maintenance would be taken care of by someone else 
rather you having to do it.

BTW, in the meta-openembedded repository there is a toolchain-layer layer that 
was intended to provide older versions of gcc; I think it hasn't been used 
much lately so it may have bitrotted, but it may be helpful for people like 
yourself who need older toolchains to club together and bring it up-to-date.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Where did my preferred version go?

[Gary Thomas]

On 2014-05-16 06:42, Paul Eggleton wrote:
> On Friday 16 May 2014 05:31:41 Gary Thomas wrote:
>> On 2014-05-16 05:16, Paul Eggleton wrote:
>>> On Friday 16 May 2014 04:50:47 Gary Thomas wrote:
>>>> On 2014-05-15 14:53, Richard Purdie wrote:
>>>>> On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
>>>>>> I have a number of platforms which [for whatever reason]
>>>>>> need older versions of GCC.  I've been supporting this by
>>>>>> keeping the older code around in my own layers - I need
>>>>>> 4.7.x for some targets, even 4.6.x for others.
>>>>>>
>>>>>> With the changes in the latest master (post 1.6/daisy), I
>>>>>> am no longer able to build those older compilers :-(  First
>>>>>> I had to fix up some core changes to just get the recipes to
>>>>>> even parse (bb.utils.contains), but now I get a slew of errors
>>>>>>
>>>>>> like these:
>>>>>>       NOTE: preferred version 4.7% of libgcc-initial not available (for
>>>>>>       item libgcc-initial) NOTE: versions of libgcc-initial available:
>>>>>>       4.8.2 4.9.0
>>>>>>
>>>>>> I looked at the old recipes and they don't provide these
>>>>>> packages which make them unsuitable.
>>>>>>
>>>>>> I know I should move these targets to the newer GCC, but at
>>>>>> this moment there simply are not the resources to do so, but
>>>>>> we still want to benefit from other improvements in OE-core
>>>>>> (and Poky/Yocto).
>>>>>>
>>>>>> How can I move forward?  Is there some way to retrofit the
>>>>>> older compilers into the new [required] structures?  Perhaps
>>>>>> I could use the older compilers as external tool chain, but
>>>>>> the last time I tried to use this (in place of the internal,
>>>>>> build in place) tools, I could never make things happy :-(
>>>>>>
>>>>>> Any suggestions more than welcome, thanks
>>>>>
>>>>> How are you doing this? Have you a completely separate set of gcc
>>>>> recipes including the include files or is this using the current include
>>>>
>>>>> files. You basically have two options:
>>>> I made a complete copy of recipes-devtools/gcc before the original 4.8
>>>> recipes were added.
>>>>
>>>>> a) Apply the changes that were made in master gcc to the 4.7 recipes,
>>>>> you can then probably share includes.
>>>>>
>>>>> b) Use a separate set of 4.7 files and "undo" some of the changes in
>>>>> master using creative variable names. E.g., libgcc-initial was added:
>>>>>
>>>>> recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers
>>>>> virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
>>>>> recipes-core/eglibc/eglibc.inc:DEPENDS =
>>>>> "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers
>>>>> virtual/${TARGET_PREFIX}libc-initial"
>>>>>
>>>>> so you could do a:
>>>>>
>>>>> DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
>>>>> DEPENDS_remove_pn-eglibc - "libgcc-initial"
>>>>>
>>>>> Thinking a bit more, the issue that is going to hit you hard are the -PN
>>>>> additions to the cross recipe changes (and their change in arch). My
>>>>> strong recommendation is therefore a) and then replaying the gcc changes
>>>>> made in master against the 4.7 version. These were:
>>>>>
>>>>> http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
>>>>>
>>>>> there are about 10 or so changes there you'd need to check in your 4.7
>>>>> recipes (since the 25th April) but nothing particularly difficult.
>>>>
>>>> Thanks for these pointers.  I've given them a quick look and indeed
>>>> they look manageable, so I'll probably give them a go.
>>>>
>>>> Do you know if anyone has ever [successfully!] used an existing
>>>> Poky/Yocto toolchain via the EXTERNAL_TOOLCHAIN method, like is
>>>> done by the meta-sourcery layers/tools?  I would think that would
>>>> be my safest bet - capture a working toolchain (I use both 4.6.3
>>>> and 4.7.2) and then enable the external support with the appropriate
>>>> toolchain/version (captured and managed out of band) for the targets
>>>> that need them.  How hard might this be?
>>>
>>> We don't support this usage at the moment in OE; if you use the OE
>>> toolchain we recommend you let the system build it, and it will then be
>>> restored from shared state for subsequent builds. I searched around for
>>> discussion on this>
>>> and coincidentally I turned up a thread you were on a few years ago:
>>>     http://comments.gmane.org/gmane.linux.embedded.poky/7049
>>>
>>> There was some discussion at the OEDAM meeting recently about trying to
>>> bring this back, but I'm pretty sure Richard is keen to avoid going down
>>> that path for the same reasons we've been avoiding it so far.
>>
>> I looked back through this thread and the enhancement bug I filed
>> (which for everyone but Richard seemed to be the way to go).  The
>> result was to reuse sstate, but I don't see how that can solve the
>> problem I have today.  How can I possibly create sstate cache files
>> for my old GCC/4.6.3 toolchain and allow them to be used with the
>> latest builds?
>
> Well, it's true that sstate won't help you solve that problem since the recipe
> still needs to be buildable (i.e. all dependencies need to be satisfied);
> sstate is rather the answer to "I want an external toolchain to avoid having
> to build the toolchain on every new build" which is a different problem.
> However, the recipes for an external toolchain must satisfy the exact same
> dependencies, so maintaining your old toolchain recipes isn't a whole lot
> different than an external toolchain at least in that respect, although you
> might argue that that maintenance would be taken care of by someone else
> rather you having to do it.
>
> BTW, in the meta-openembedded repository there is a toolchain-layer layer that
> was intended to provide older versions of gcc; I think it hasn't been used
> much lately so it may have bitrotted, but it may be helpful for people like
> yourself who need older toolchains to club together and bring it up-to-date.

I just tried the meta-sourcery (old CSL) layer and it worked a treat.
I only had to add that layer and define a single variable to point to
their tools.  Next week, I think I'll have a go at adapting their layer
to use an OE derived toolchain.

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

Re: Where did my preferred version go?

[Khem Raj]

On Fri, May 16, 2014 at 10:11 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2014-05-16 06:42, Paul Eggleton wrote:
>>
>> On Friday 16 May 2014 05:31:41 Gary Thomas wrote:
>>>
>>> On 2014-05-16 05:16, Paul Eggleton wrote:
>>>>
>>>> On Friday 16 May 2014 04:50:47 Gary Thomas wrote:
>>>>>
>>>>> On 2014-05-15 14:53, Richard Purdie wrote:
>>>>>>
>>>>>> On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
>>>>>>>
>>>>>>> I have a number of platforms which [for whatever reason]
>>>>>>> need older versions of GCC.  I've been supporting this by
>>>>>>> keeping the older code around in my own layers - I need
>>>>>>> 4.7.x for some targets, even 4.6.x for others.
>>>>>>>
>>>>>>> With the changes in the latest master (post 1.6/daisy), I
>>>>>>> am no longer able to build those older compilers :-(  First
>>>>>>> I had to fix up some core changes to just get the recipes to
>>>>>>> even parse (bb.utils.contains), but now I get a slew of errors
>>>>>>>
>>>>>>> like these:
>>>>>>>       NOTE: preferred version 4.7% of libgcc-initial not available
>>>>>>> (for
>>>>>>>       item libgcc-initial) NOTE: versions of libgcc-initial
>>>>>>> available:
>>>>>>>       4.8.2 4.9.0
>>>>>>>
>>>>>>> I looked at the old recipes and they don't provide these
>>>>>>> packages which make them unsuitable.
>>>>>>>
>>>>>>> I know I should move these targets to the newer GCC, but at
>>>>>>> this moment there simply are not the resources to do so, but
>>>>>>> we still want to benefit from other improvements in OE-core
>>>>>>> (and Poky/Yocto).
>>>>>>>
>>>>>>> How can I move forward?  Is there some way to retrofit the
>>>>>>> older compilers into the new [required] structures?  Perhaps
>>>>>>> I could use the older compilers as external tool chain, but
>>>>>>> the last time I tried to use this (in place of the internal,
>>>>>>> build in place) tools, I could never make things happy :-(
>>>>>>>
>>>>>>> Any suggestions more than welcome, thanks
>>>>>>
>>>>>>
>>>>>> How are you doing this? Have you a completely separate set of gcc
>>>>>> recipes including the include files or is this using the current
>>>>>> include
>>>>>
>>>>>
>>>>>> files. You basically have two options:
>>>>>
>>>>> I made a complete copy of recipes-devtools/gcc before the original 4.8
>>>>> recipes were added.
>>>>>
>>>>>> a) Apply the changes that were made in master gcc to the 4.7 recipes,
>>>>>> you can then probably share includes.
>>>>>>
>>>>>> b) Use a separate set of 4.7 files and "undo" some of the changes in
>>>>>> master using creative variable names. E.g., libgcc-initial was added:
>>>>>>
>>>>>> recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers
>>>>>> virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
>>>>>> recipes-core/eglibc/eglibc.inc:DEPENDS =
>>>>>> "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers
>>>>>> virtual/${TARGET_PREFIX}libc-initial"
>>>>>>
>>>>>> so you could do a:
>>>>>>
>>>>>> DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
>>>>>> DEPENDS_remove_pn-eglibc - "libgcc-initial"
>>>>>>
>>>>>> Thinking a bit more, the issue that is going to hit you hard are the
>>>>>> -PN
>>>>>> additions to the cross recipe changes (and their change in arch). My
>>>>>> strong recommendation is therefore a) and then replaying the gcc
>>>>>> changes
>>>>>> made in master against the 4.7 version. These were:
>>>>>>
>>>>>>
>>>>>> http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
>>>>>>
>>>>>> there are about 10 or so changes there you'd need to check in your 4.7
>>>>>> recipes (since the 25th April) but nothing particularly difficult.
>>>>>
>>>>>
>>>>> Thanks for these pointers.  I've given them a quick look and indeed
>>>>> they look manageable, so I'll probably give them a go.
>>>>>
>>>>> Do you know if anyone has ever [successfully!] used an existing
>>>>> Poky/Yocto toolchain via the EXTERNAL_TOOLCHAIN method, like is
>>>>> done by the meta-sourcery layers/tools?  I would think that would
>>>>> be my safest bet - capture a working toolchain (I use both 4.6.3
>>>>> and 4.7.2) and then enable the external support with the appropriate
>>>>> toolchain/version (captured and managed out of band) for the targets
>>>>> that need them.  How hard might this be?
>>>>
>>>>
>>>> We don't support this usage at the moment in OE; if you use the OE
>>>> toolchain we recommend you let the system build it, and it will then be
>>>> restored from shared state for subsequent builds. I searched around for
>>>> discussion on this>
>>>> and coincidentally I turned up a thread you were on a few years ago:
>>>>     http://comments.gmane.org/gmane.linux.embedded.poky/7049
>>>>
>>>> There was some discussion at the OEDAM meeting recently about trying to
>>>> bring this back, but I'm pretty sure Richard is keen to avoid going down
>>>> that path for the same reasons we've been avoiding it so far.
>>>
>>>
>>> I looked back through this thread and the enhancement bug I filed
>>> (which for everyone but Richard seemed to be the way to go).  The
>>> result was to reuse sstate, but I don't see how that can solve the
>>> problem I have today.  How can I possibly create sstate cache files
>>> for my old GCC/4.6.3 toolchain and allow them to be used with the
>>> latest builds?
>>
>>
>> Well, it's true that sstate won't help you solve that problem since the
>> recipe
>> still needs to be buildable (i.e. all dependencies need to be satisfied);
>> sstate is rather the answer to "I want an external toolchain to avoid
>> having
>> to build the toolchain on every new build" which is a different problem.
>> However, the recipes for an external toolchain must satisfy the exact same
>> dependencies, so maintaining your old toolchain recipes isn't a whole lot
>> different than an external toolchain at least in that respect, although
>> you
>> might argue that that maintenance would be taken care of by someone else
>> rather you having to do it.
>>
>> BTW, in the meta-openembedded repository there is a toolchain-layer layer
>> that
>> was intended to provide older versions of gcc; I think it hasn't been used
>> much lately so it may have bitrotted, but it may be helpful for people
>> like
>> yourself who need older toolchains to club together and bring it
>> up-to-date.
>
>
> I just tried the meta-sourcery (old CSL) layer and it worked a treat.
> I only had to add that layer and define a single variable to point to
> their tools.  Next week, I think I'll have a go at adapting their layer
> to use an OE derived toolchain.

You best course of action here is to keep mimicing the toolchain build
sequence changes as you hop major releases
similar exercise that external toolchain guys have to do. Its a constant battle.

>
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Where did my preferred version go?

[Gary Thomas]

On 2014-05-15 14:53, Richard Purdie wrote:
> On Wed, 2014-05-14 at 12:06 -0600, Gary Thomas wrote:
>> I have a number of platforms which [for whatever reason]
>> need older versions of GCC.  I've been supporting this by
>> keeping the older code around in my own layers - I need
>> 4.7.x for some targets, even 4.6.x for others.
>>
>> With the changes in the latest master (post 1.6/daisy), I
>> am no longer able to build those older compilers :-(  First
>> I had to fix up some core changes to just get the recipes to
>> even parse (bb.utils.contains), but now I get a slew of errors
>> like these:
>>
>>     NOTE: preferred version 4.7% of libgcc-initial not available (for item libgcc-initial)
>>     NOTE: versions of libgcc-initial available: 4.8.2 4.9.0
>>
>> I looked at the old recipes and they don't provide these
>> packages which make them unsuitable.
>>
>> I know I should move these targets to the newer GCC, but at
>> this moment there simply are not the resources to do so, but
>> we still want to benefit from other improvements in OE-core
>> (and Poky/Yocto).
>>
>> How can I move forward?  Is there some way to retrofit the
>> older compilers into the new [required] structures?  Perhaps
>> I could use the older compilers as external tool chain, but
>> the last time I tried to use this (in place of the internal,
>> build in place) tools, I could never make things happy :-(
>>
>> Any suggestions more than welcome, thanks
>
> How are you doing this? Have you a completely separate set of gcc
> recipes including the include files or is this using the current include
> files. You basically have two options:
>
> a) Apply the changes that were made in master gcc to the 4.7 recipes,
> you can then probably share includes.
>
> b) Use a separate set of 4.7 files and "undo" some of the changes in
> master using creative variable names. E.g., libgcc-initial was added:
>
> recipes-core/eglibc/eglibc-initial.inc:DEPENDS = "linux-libc-headers virtual/${TARGET_PREFIX}gcc-initial libgcc-initial"
> recipes-core/eglibc/eglibc.inc:DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers virtual/${TARGET_PREFIX}libc-initial"
>
> so you could do a:
>
> DEPENDS_remove_pn-eglibc-initial - "libgcc-initial"
> DEPENDS_remove_pn-eglibc - "libgcc-initial"
>
> Thinking a bit more, the issue that is going to hit you hard are the -PN
> additions to the cross recipe changes (and their change in arch). My
> strong recommendation is therefore a) and then replaying the gcc changes
> made in master against the 4.7 version. These were:
>
> http://git.yoctoproject.org/cgit.cgi/poky/log/meta/recipes-devtools/gcc
>
> there are about 10 or so changes there you'd need to check in your 4.7
> recipes (since the 25th April) but nothing particularly difficult.

I've done this (as you said, nothing too difficult) and it seems to
be working.  My only issue is that I had a deep copy of the old
recipes-devtools/gcc with both the 4.6 and 4.7 recipes included.
This seemed to cause some conflicts if my layer with these recipes
was included when building with GCC 4.8+, in particular when building
the most recent eglibc as pre 4.8 there was no unwind (or different)
support and this is now required.  My solution was to move these
older recipes to a separate layer which is only included for targets
that need the ancient tools, which seems reasonable anyway.

My hope is to find time to move those targets to newer compilers
before I have to do this after the next big toolchain shake-up,
whenever that may be :-)

Thanks for the help

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