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


--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to