gcc 5.2 failures

gcc 5.2 failures

[Richard Purdie]

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

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?

Otavio: The freescale machines are looking unwell, can you help us make
sure the right people know about this?

Cheers,

Richard

Re: gcc 5.2 failures

[Mike Looijmans]

Wow, 5.2? I can't even get the broadcom MIPS kernels to compile using the 
current master's 4.9.3 (I'm investigating still whether the kernel or gcc or 
OE is the problem here).

M.

On 27-07-15 11:30, 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
>
> 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?
>
> Otavio: The freescale machines are looking unwell, can you help us make
> sure the right people know about this?
>
> Cheers,
>
> Richard
>
>
>
>



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: gcc 5.2 failures

[Bruce Ashfield]

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.

>
> 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.

Cheers,

Bruce

>
> Otavio: The freescale machines are looking unwell, can you help us make
> sure the right people know about this?
>
> Cheers,
>
> Richard
>
>
>
>

Re: gcc 5.2 failures

[Yi Qingliang]

using gcc 5.1, the boost statechart library compile fail.

On Mon, Jul 27, 2015 at 9:20 PM, Bruce Ashfield
<bruce.ashfield@windriver.com> 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.
>
>>
>> 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.
>
> Cheers,
>
> Bruce
>
>>
>> Otavio: The freescale machines are looking unwell, can you help us make
>> sure the right people know about this?
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: gcc 5.2 failures

[Bruce Ashfield]

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=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.
>
>>
>> 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 :)

Bruce

>
> Cheers,
>
> Bruce
>
>>
>> Otavio: The freescale machines are looking unwell, can you help us make
>> sure the right people know about this?
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
>

Re: gcc 5.2 failures

[Paul Eggleton]

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...

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: gcc 5.2 failures

[Richard Purdie]

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?

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...

Cheers,

Richard

Re: gcc 5.2 failures

[Bruce Ashfield]

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
>

Re: gcc 5.2 failures

[Bruce Ashfield]

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
>

Re: gcc 5.2 failures

[Khem Raj]

On Mon, Jul 27, 2015 at 2:30 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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).
>

errors like http://errors.yoctoproject.org/Errors/Details/13821/
should be fixed with glibc 2.22 now there was symbol visibility fix
which went into gcc5
binutils 2.25+ and glibc 2.22+, I did not backport the glibc piece to
2.21, as I knew 2.22 was releasing.