Re: Where did my preferred version go?

[Gary Thomas <gary@mlbassoc.com>]

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