| Summary: | www-client/chromium-117.0.5938.88 fails to compile with dev-util/gn-0.2077 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | François Valenduc <francoisvalenduc> |
| Component: | Current packages | Assignee: | Chromium Project <chromium> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ionen, kangie |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build log | ||
|
Description
François Valenduc
2023-09-18 05:03:56 UTC
please attach the full build.log. As I said, compilation fails right away. The full build log is already in the bug. What precedes the "Source prepated" line is the usual decompression of the sources and the application of the patches. Created attachment 870830 [details]
build log
(In reply to François Valenduc from comment #2) > As I said, compilation fails right away. It's built fine for me, but the build.log is the format we expect, and it has the effective USE flags for the build, as well as other information at the start. I'm not sure exactly what's going on here.
You seem to have somehow ended up trying to configure a test target for blink.
That target is seemingly broken, hence the below:
```
ERROR at //third_party/blink/renderer/core/BUILD.gn:1697:14: Assignment had no effect.
mnemonic = "ELOC_PROTO"
^-----------
You set the variable "mnemonic" here and it was unused before it went
out of scope.
```
You shouldn't be going down that codepath though; we don't include any 'test' mechanism for Chromium.
I can't reproduce this issue on my dev machine with identical USE flags...
[ebuild R ~] www-client/chromium-117.0.5938.88:0/stable::gentoo USE="X cups hangouts kerberos* official (pic) proprietary-codecs pulseaudio qt5 suid system-harfbuzz system-icu system-png system-zstd widevine* (-component-build) -custom-cflags -debug -gtk4* (-headless) -libcxx -lto -pax-kernel (-pgo) -qt6 -screencast* (-selinux) (-system-av1) (-system-ffmpeg) -vaapi -wayland*" L10N="-af -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -ur -vi -zh-CN -zh-TW" 0 KiB Haven't tried myself, but have you tried with stable dev-util/gn? This is a stable system and I was looking at [1] and it mentions mnemonic [1] https://github.com/chromium/chromium/commit/2d9d3c9fdbd972825616e32e25ca6c12b2dadaec (In reply to Ionen Wolkens from comment #7) > Haven't tried myself, but have you tried with stable dev-util/gn? This is a > stable system and I was looking at [1] and it mentions mnemonic > > [1] > https://github.com/chromium/chromium/commit/ > 2d9d3c9fdbd972825616e32e25ca6c12b2dadaec I was just about to ask about gn version.. I am using the current stable version of gn (0.2077). Should I try with a newer one ? (In reply to Ionen Wolkens from comment #7) > Haven't tried myself, but have you tried with stable dev-util/gn? This is a > stable system and I was looking at [1] and it mentions mnemonic > Nailed it. Builds fail with stable gn. @François Valenduc; you can retry after unmasking a 'testing' (~arch) version of gn. Longer term, is there a reason _not_ to use the bundled gn? The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=050682eae3589e969d9adda25c022c7c5e527c5b commit 050682eae3589e969d9adda25c022c7c5e527c5b Author: Matt Jolly <Matt.Jolly@footclan.ninja> AuthorDate: 2023-09-18 06:22:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-18 06:26:13 +0000 www-client/chromium: update `dev-util/gn` dependency for 117 Closes: https://bugs.gentoo.org/914370 Signed-off-by: Matt Jolly <Matt.Jolly@footclan.ninja> Closes: https://github.com/gentoo/gentoo/pull/32893 Signed-off-by: Sam James <sam@gentoo.org> www-client/chromium/chromium-117.0.5938.88.ebuild | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (In reply to Matt Jolly from comment #10) > Longer term, is there a reason _not_ to use the bundled gn? Perhaps if it handles bootstrapping gn badly for cross-compilation like qtwebengine:6 does. Not that I ever really looked at chromium proper without Qt's cmake wrappers. Either way, lower bound for gn could be bumped aggressively rather than worry about "lowest that works". Indeed, it compiles fine with a newer version of gn (0.2114). Thanks for your help. |
