From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id A4D3FE00B68; Fri, 16 May 2014 04:31:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=no version=3.3.1 X-Spam-HAM-Report: * 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS Received: from mail.chez-thomas.org (unknown [65.100.170.105]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 3CE82E00975 for ; Fri, 16 May 2014 04:31:30 -0700 (PDT) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id 89B34F811F8; Fri, 16 May 2014 05:31:30 -0600 (MDT) Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id 47D9CF811E0; Fri, 16 May 2014 05:31:29 -0600 (MDT) Message-ID: <5375F71D.3020607@mlbassoc.com> Date: Fri, 16 May 2014 05:31:41 -0600 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Eggleton References: <5373B0AB.4070204@mlbassoc.com> <1400187220.28353.15.camel@ted> <5375ED87.1000605@mlbassoc.com> <70015786.1gtbouFiKb@peggleto-mobl5.ger.corp.intel.com> In-Reply-To: <70015786.1gtbouFiKb@peggleto-mobl5.ger.corp.intel.com> Cc: yocto@yoctoproject.org Subject: Re: Where did my preferred version go? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:31:35 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 ------------------------------------------------------------