Created attachment 352414 [details] chromium-28.0.1500.63-build.log.tar.xz On Fri Jun 21 09:14:46EST 2013 I was able to emerge www-client/chromium-28.0.1500.52 without issue. This was followed later with an update of the, (FireBurn overlay), live ebuild of media-libs/mesa-9999-r51 on Fri Jun 21 17:32:38EST 2013. Since that update, emerging both www-client/chromium-28.0.1500.52 and www-client/chromium-28.0.1500.63 fails compilation in ui/gl/gl_fence.cc:87:35: error: 'struct gfx::ExtensionsGL' has no member named 'b_GL_ARB_sync'
Created attachment 352416 [details] emerge --info
Same problem here, but www-client/chromium-28.0.1500.52 fails as well.
Comment on attachment 352414 [details] chromium-28.0.1500.63-build.log.tar.xz Why put a single file in a tar archive?
Created attachment 352464 [details] chromium-28.0.1500.63-build.log.zip (In reply to Jeroen Roovers from comment #3) > Comment on attachment 352414 [details] > chromium-28.0.1500.63-build.log.tar.xz > > Why put a single file in a tar archive? My mistake. I used Ark to compress the build log, (for the first time), and I selected "Compress to" and thought I was choosing XZ-compressed. Instead I see now that the menu choice is actually TAR archive (XZ-compressed). Here it is. Single file. Zipped.
This is not restricted to the FireBurn overlay but happens also with the x11 overlay mesa-9999.
I can confirm this same problem with mesa-9999 Fireburn live builds. worked before an update, and not after.
Looking at upstream's repo, it seems that the failing code is still there. Not sure if includes weren't changed though.
It's probably related to this commit made 2 weeks ago: http://cgit.freedesktop.org/mesa/mesa/commit/include/GL/glext.h?id=9a14e412d6de93349a490a9c4534b52c3b524ee9 Has anyone tried compiling Chromium since then?
I just tried to build chromium-28.0.1500.89 without success and got the same error. Last time I was able to build chromium was Sun Jun 9 17:37:37 2013, version 27.0.1453.110. I'm using mesa-9999 from x11 overlay, built Mon Jul 8 18:53:24 2013.
I don't really intend to take any action on this until we see it with an actual release of mesa. If someone else wants to provide a patch, that would be welcome, but we will need to get it committed upstream first.
After updating all of my live ebuilds today, (using smart-live-rebuild), which included an update to mesa, emerging www-client/chromium-28.0.1500.89 still fails with this error condition.
Well, it seems that the changes to mesa headers confuse the chromium generators. I was able to compile chromium successfully through adding all the missing booleans by hand. I'd really appreciate if someone with a clean build log could report this upstream, please.
As a temporary workaround I downgraded to mesa-9.1.4 installed chromium and went back to 9999 without issues
I think this is Chromium's bug since Mesa just takes the header from Khronos.
And so, any bug fix for us?..
Ping.
This also fails against 9.2 branch of mesa, which is scheduled for release this month.
I believe phajdan.jr is planning to change the ebuild to build with bundled headers since we load the libraries using dlopen() anyway. https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/amyyjkDj7Cg
+*chromium-30.0.1588.0 (13 Aug 2013) + + 13 Aug 2013; Pawel Hajdan jr <phajdan.jr@gentoo.org> + -chromium-30.0.1568.0.ebuild, +chromium-30.0.1588.0.ebuild, + chromium-9999-r1.ebuild: + Dev channel bump. Fix bug #479418 by floppym. Fix bug #473260 by Vladimir. + Exclude a failing test (bug #478168). Stop using system mesa. Temporarily use + bundled openssl. Remove old. It looks like this problem is fixed in chromium-30.0.1588. Will you also fix this in ~arch? I would like to drop the p.mask on mesa, and likely many chromium users will run into this problem then.
(In reply to Chí-Thanh Christopher Nguyễn from comment #19) 14 Aug 2013; Pawel Hajdan jr <phajdan.jr@gentoo.org> chromium-29.0.1547.41.ebuild: Switch back to make build (ninja build has issues like bug #471272). Also do not use system mesa, bug #475444 .
Marking as fixed per comment 20.
(In reply to Chí-Thanh Christopher Nguyễn from comment #21) > Marking as fixed per comment 20. Makes sense only after unmasking 30 in ~testing and masking 28/29 in stable.
Stable tree is not affected, because stable chromium-28 builds against stable mesa-9.1 Unstable tree is not affected, because unstable chromium-29 builds against unstable mesa-9.2 (per comment 20). That is enough justification for marking this bug as fixed, I think.
