Summary: | www-client/chromium-53.0.2785.34[gn] fails to build with clang | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dominik Strehlke <dominik> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Dominik Strehlke
2016-08-02 19:11:18 UTC
Thanks for the report! I landed https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/chromium?id=9ba81cafcad5753ea8cdc3ee7615187a30128f92 but unfortunately I'm still hitting some errors e.g. with 54.0.2810.2 : warning: unknown warning option '-Wno-undefined-var-template'; did you mean '-Wno-undefined-internal'? [-Wunknown-warning-option] warning: unknown warning option '-Wno-nonportable-include-path'; did you mean '-Wno-gnu-include-next'? [-Wunknown-warning-option] (In reply to Paweł Hajdan, Jr. from comment #1) That escaping is pretty ugly. Do you mind if I convert some of the string variables in the chromium ebuild into bash arrays? They look so much cleaner and are easier to work with. (In reply to Mike Gilbert from comment #2) > That escaping is pretty ugly. > > Do you mind if I convert some of the string variables in the chromium ebuild > into bash arrays? They look so much cleaner and are easier to work with. Go ahead. :) (In reply to Paweł Hajdan, Jr. from comment #1) > Thanks for the report! > > I landed > https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/ > chromium?id=9ba81cafcad5753ea8cdc3ee7615187a30128f92 but unfortunately I'm > still hitting some errors e.g. with 54.0.2810.2 : > > warning: unknown warning option '-Wno-undefined-var-template'; did you mean > '-Wno-undefined-internal'? [-Wunknown-warning-option] > warning: unknown warning option '-Wno-nonportable-include-path'; did you > mean '-Wno-gnu-include-next'? [-Wunknown-warning-option] Ummm you say you're hitting errors, but what you pasted are warnings right? :-) Those warnings seem to come up every time when compiling with clang, I already had those when building with gyp and got perfectly working chromium packages. IF this is a bug, it's probably upstream and does not have anything to do with this particular bug, as those warnings were already thrown without gn. Ah, you're right. This is the real error - with chromium-54.0.2832.2 and clang-3.8.1-r100 . ../../services/ui/public/cpp/gles2_context.cc:52:37: error: default initialization of an object of const type 'const gpu::SharedMemoryLimits' without a user-provided default constructor constexpr gpu::SharedMemoryLimits default_limits; ^ {} 2 warnings and 1 error generated. Yes, I was getting that as well. It was easy to fix by adding a default constructor in the mentioned header file. Still, in a gyp based build this error does not occur. Also, the generated binary from my gn build proved to be extremely unstable, being unresponsive after a few minutes. Of course, I cannot say if that is the result of my "fix" of that header that produced the error, but still the error is very weird. Have you tried the gn build with a currect preview version of clang? Anyway, llvm 3.9 should be released tomorrow and I will try the gn build again as soon as it's there. (In reply to Paweł Hajdan, Jr. from comment #5) > Ah, you're right. This is the real error - with chromium-54.0.2832.2 and > clang-3.8.1-r100 . > > ../../services/ui/public/cpp/gles2_context.cc:52:37: error: default > initialization of an object of const type 'const gpu::SharedMemoryLimits' > without a user-provided default constructor > constexpr gpu::SharedMemoryLimits default_limits; > ^ > {} > 2 warnings and 1 error generated. services/ui/public/cpp/gles2_context.cc services/ui/surfaces/surfaces_context_provider.cc could be built with clang-3.9 without *constexpr* error. My original reported bug was fixed. Pawel's first commit fixed it all. The warnings that still came up had nothing to do with this and disappeared with LLVM 3.9. The issue that remains is the unstable binary but that is being addressed in bug 591938 already. I'm closing this as my issue is fixed. |