gcc 5.2 failures
I've run a gcc 5.2 test build on the autobuilder:
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
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.
Quoted 30 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
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?
Quoted 10 lines
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: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
Quoted 4 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
Quoted 8 lines
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.
Quoted 9 lines
openssl issue for p1022ds
u-boot on imx28evk, p1022ds, mpc8315e-rdb
xf86-video-imxfb-vivante on imx6qsabresd
linux-imx issue on imx53qsb
Quoted 8 lines
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
Quoted 11 lines
Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this?
Cheers,
Richard
using gcc 5.1, the boost statechart library compile fail.
Quoted 69 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
Quoted 8 lines
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.
Quoted 9 lines
openssl issue for p1022ds
u-boot on imx28evk, p1022ds, mpc8315e-rdb
xf86-video-imxfb-vivante on imx6qsabresd
linux-imx issue on imx53qsb
Quoted 8 lines
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
Quoted 11 lines
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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 36 lines · Bruce Ashfield
Quoted 5 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
Quoted 8 lines
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.
Quoted 9 lines
openssl issue for p1022ds
u-boot on imx28evk, p1022ds, mpc8315e-rdb
xf86-video-imxfb-vivante on imx6qsabresd
linux-imx issue on imx53qsb
Quoted 8 lines
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?
Quoted 8 lines
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
Quoted 17 lines
Cheers,
Bruce
Quoted 11 lines
Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this?
Cheers,
Richard
Quoted 46 lines · On Monday 27 July 2015 09:31:01 Bruce Ashfield wrote:
Quoted 36 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
http://errors.yoctoproject.org/Errors/Search/?items=10&query=3628c3c06fa4
195003ac655bcc791acfac775173&limit=50Quoted 8 lines
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.
Quoted 8 lines
openssl issue for p1022ds
u-boot on imx28evk, p1022ds, mpc8315e-rdb
xf86-video-imxfb-vivante on imx6qsabresd
linux-imx issue on imx53qsb
Quoted 8 lines
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?
Quoted 8 lines
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.
Quoted 4 lines
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
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 47 lines · Paul Eggleton
Quoted 46 lines · On Monday 27 July 2015 09:31:01 Bruce Ashfield wrote:
Quoted 44 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
http://errors.yoctoproject.org/Errors/Search/?items=10&query=3628c3c06fa4
195003ac655bcc791acfac775173&limit=50Quoted 8 lines
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.
Quoted 8 lines
openssl issue for p1022ds
u-boot on imx28evk, p1022ds, mpc8315e-rdb
xf86-video-imxfb-vivante on imx6qsabresd
linux-imx issue on imx53qsb
Quoted 8 lines
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.
Quoted 8 lines
Quoted 4 lines
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
Quoted 4 lines
Cheers,
Paul
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
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:
Quoted 5 lines
Quoted 2 lines
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".
Quoted 11 lines
Quoted 2 lines
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
Quoted 12 lines · Richard Purdie
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
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:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 19 lines
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 directorywhich doesn't look "5.2".
Quoted 11 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 5 lines
Cheers,
Richard
Quoted 6 lines · Richard Purdie
I've run a gcc 5.2 test build on the autobuilder:
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.