From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id D64F1601F7 for ; Mon, 27 Jul 2015 13:55:11 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.15.1/8.15.1) with ESMTPS id t6RDt9XK012931 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 06:55:09 -0700 (PDT) Received: from [128.224.56.48] (128.224.56.48) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.235.1; Mon, 27 Jul 2015 06:54:54 -0700 Message-ID: <55B63836.8050608@windriver.com> Date: Mon, 27 Jul 2015 09:55:02 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Eggleton , References: <1437989436.821.221.camel@linuxfoundation.org> <55B6300F.7060104@windriver.com> <55B63295.6090006@windriver.com> <13075359.ly3sbSCPpg@peggleto-mobl.ger.corp.intel.com> In-Reply-To: <13075359.ly3sbSCPpg@peggleto-mobl.ger.corp.intel.com> Cc: Otavio Salvador Subject: Re: gcc 5.2 failures X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 13:55:13 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 15-07-27 09:50 AM, Paul Eggleton wrote: > On Monday 27 July 2015 09:31:01 Bruce Ashfield wrote: >> On 15-07-27 09:20 AM, Bruce Ashfield wrote: >>> On 15-07-27 05:30 AM, Richard Purdie wrote: >>>> I've run a gcc 5.2 test build on the autobuilder: >>>> >>>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=3628c3c06fa4 >>>> 195003ac655bcc791acfac775173&limit=50 >>>> >>>> >>>> 41 errors (with a few more pending). >>>> >>>> The good news is that if we tweak the security flags, the poky-lsb gcc, >>>> elfutils, coreutils and iptables issues can be removed and I have a >>>> patch for this. This leaves: >>>> >>>> 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, >>>> mpc8315e-rdb >>> >>> Gah. I had all these building with 5.1 .. chasing gcc is a pain >>> with this older kernel. >>> >>>> openssl issue for p1022ds >>>> >>>> u-boot on imx28evk, p1022ds, mpc8315e-rdb >>>> >>>> xf86-video-imxfb-vivante on imx6qsabresd >>>> >>>> linux-imx issue on imx53qsb >>>> >>>> Some kind of "random" qemu runtime issue (4 cases). >>>> >>>> At this point I think we likely need to enter bugs into the bugzilla for >>>> each of these. If we want to switch 1.9 to use this (which I think is >>>> desirable), we need to get this fixed as a priority. >>>> >>>> Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix >>>> 3.14? >>> >>> Now that 4.1 is in place, and I can't really see a large user base that >>> needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using >>> master with their own kernel's will obviously have to deal with the >>> issue in their trees) .. join that with the fact that we need to update >>> all the reference boards to 4.1 anyway, my suggestion is that we open >>> bugs for the h/w reference updates (and I'll get the appropriate Wind >>> River eyes on them) and walk away from burning more cycles on gcc 5.x >>> and the 3.14 kernel. >> >> And of course, I remembered that we updated all the reference >> boards to 3.19, so if 3.19 builds with gcc 5.2 (it may not), then >> all we need to do is move the lsb reference to 4.1 and we'll also >> be free of backporting :) > > It would be nice if we were able to point to a set of fixes that people can > apply onto their older kernels in the migration guide for 1.9 though - I > guarantee we'll get people asking... There's unfortunately no clean set of fixes, the mips one for example, is a bit of a knarly backport in the assembly code. If it was easy to point them out, we would have just done all the ports :) Bruce > > Cheers, > Paul >