All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Otavio Salvador <otavio@ossystems.com.br>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: gcc 5.2 failures
Date: Mon, 27 Jul 2015 09:55:55 -0400	[thread overview]
Message-ID: <55B6386B.7010408@windriver.com> (raw)
In-Reply-To: <1438005162.821.253.camel@linuxfoundation.org>

On 15-07-27 09:52 AM, Richard Purdie wrote:
> On Mon, 2015-07-27 at 09:20 -0400, 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=3628c3c06fa4195003ac655bcc791acfac775173&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.
>
> I'm not sure if this is a 5.1 verses 5.2 issue or not. I'm starting to
> wonder if the SRCREVs we're using pull in the gcc 5.x fixes?

Hmm. True enough, I'll double check, since I did have everything
building against 5.1 about a week ago.

>
> E.g. one of the failures was:
>
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work-shared/beaglebone/kernel-source/include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc5.h: No such file or directory
>
> which doesn't look "5.2".
>
>>> 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.
>
> That seems reasonable to me, assuming we don't have an easy SRCREV fix
> we've just missed/lost somehow...

I'll get back to you on that one, I'm turning 5.x back on in my
local builds.

Bruce

>
> Cheers,
>
> Richard
>



  reply	other threads:[~2015-07-27 13:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27  9:30 gcc 5.2 failures Richard Purdie
2015-07-27 10:56 ` Mike Looijmans
2015-07-27 13:20 ` Bruce Ashfield
2015-07-27 13:24   ` Yi Qingliang
2015-07-27 13:31   ` Bruce Ashfield
2015-07-27 13:50     ` Paul Eggleton
2015-07-27 13:55       ` Bruce Ashfield
2015-07-27 13:52   ` Richard Purdie
2015-07-27 13:55     ` Bruce Ashfield [this message]
2015-08-11  0:15 ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55B6386B.7010408@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.