[yocto] 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