On my system with 32GB for /var/tmp/portage chromium refused to build after build.log have grown to 22GB and caused disk space outage. An option to make build.log a FIFO of some maximal length (in MB) would resolve this problem (to set in make.conf)
I'm suspicious of the claim that the build.log *itself* was that large, but even then, we certainly don't want to be truncating it or anything like that as it would make bug reports very challenging. If it *is* that large, that implies something is going wrong with e.g. tonnes of warnings or similar that we should look at suppressing. Seeing a sample of it would help.
Created attachment 916384 [details] build.log - last 1000 lines (screen hardcopy)
emerge --info too please?
Are you doing something like passing flags to enable extra warnings?
> Are you doing something like passing flags to enable extra warnings? No. But I've just realized, what I was doing wrong: I switched to clang and chromium does not like it... Changed to gcc in package.env and will let you know.
The ebuild forces using Clang these days (transparently) because can't be built with GCC, but it's possible there was some error in how you were trying to make it use Clang, maybe?
13% lines of build log is: warning: this style of line directive is a GNU extension [-Wgnu-line-marker]
And the rest looks like: 18 | # 1 "../../v8/include/v8-context.h" 1 | ^ In file included from ../../v8/src/maglev/maglev-regalloc.cc:5: In file included from ../../v8/src/maglev/maglev-regalloc.h:9: In file included from ../../v8/src/compiler/backend/instruction.h:19: In file included from ../../v8/src/compiler/common-operator.h:14: In file included from ../../v8/src/compiler/feedback-source.h:8: In file included from ../../v8/src/compiler/heap-refs.h:11: In file included from ../../v8/src/ic/call-optimization.h:10: In file included from ../../v8/src/api/api-arguments.h:9: In file included from ../../v8/src/builtins/builtins-utils.h:10: In file included from ../../v8/src/execution/arguments.h:10: In file included from ../../v8/src/logging/runtime-call-stats-scope.h:10: In file included from ../../v8/src/execution/isolate.h:18: ../../v8/include/v8-context.h:1:6: warning: this style of line directive is a GNU extension [-Wgnu-line-marker]
Can you show me the first 1000 lines or so of the build.log? I still don't get where that's coming from.
(In reply to Sam James from comment #9) > Can you show me the first 1000 lines or so of the build.log? I still don't > get where that's coming from. Changes in make.conf for clang: CC=clang CXX=clang++ AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib LDFLAGS="-Wl,-O1 -Wl,--as-needed -fuse-ld=lld" # ^^^ chromium did not link with mold I use distcc and ccache. USE="X cups custom-cflags gtk4 hangouts proprietary-codecs pulseaudio screencast system-harfbuzz system-zstd vaapi wayland widevine" build.log - I will attach 1024 lines to make it easier :-D
Created attachment 916551 [details] first 1024 lines
Created attachment 916552 [details] first 1024 lines of build.log without ncurses colors
Well that _is_ odd. As Sam mentioned, the Chromium ebuild forces Clang 19 at the moment. It _should_ work with CC=clang though, we don't do anything fancy, just set CC and friends to variations on `CC="${CHOST}-clang-${LLVM_SLOT}"` I build on a 32G ramdisk and haven't hit this issue (yet), but I'll keep an eye out. You don't have `-pedantic` in CFLAGS or something?
> You don't have `-pedantic` in CFLAGS or something? Quite the opposite... :-D -fpermissive sometimes, but in make.conf only "-pipe -O2 -march=nocona" (no SIGILL on AMD nor Intel ;-))
Can we see both emerge --info and the environment file for chromium (it's in temp/ in the builddir)?
I think it might be being caused by distcc.
> I think it might be being caused by distcc. I underestimated you :-D It is! No distcc -- no warnings :-D
I have the same problem, building chromium with distcc floods build.log with warnings and disk runs out of space. Although "don't use distcc, works for me" is for many a solution, I have an old laptop where chromium build takes over a full day without distcc. chromium 131 worked fine, 132 no longer works Any hint how to suppress this log spam appreciated... what changed? Thank you!
> Although "don't use distcc, works for me" is for many a solution [...] Sorry. I found no good reason, and "worksforme" just sounds funny. Who thinks it is a distcc problem?
[many, many hours later] Chromium 132 takes ~16.5G /var/tmp/portage space to build normally. However, it takes ~54.5G to build with distcc (a 2 workers on LAN), of which just build.log takes up ~37G and has ~433 millions lines of text. Also, at the end between "Final size" and "QA Notice" something takes a VERY long time with one core maxed, unfortunately losing a lot of time gained by distcc compilation. As Sam suggested, I compared "environment" with and without distcc - no noteworthy difference. I also tried to compare compile calls itself, I see no difference or -pendantic flag either. No idea why distcc builds blow up like that :-/
Last build took >40GB build.log and does'nt finish due to out of space. most log lines are from -Wgnu-line-marker warnings, so I added an env file for www-client/chromium in /etc/portage/package.env in that environment are additional CFLAGS and CXXFLAGS: -Wno-gnu-line-marker this lets it build using distcc again without that huge build.log
> -Wno-gnu-line-marker Great job!
> -Wno-gnu-line-marker Thank you for your detective work! Unfortunately, I cannot retest with 133 due to https://bugs.gentoo.org/948384 ... :-/
Tried 133.xxx.98 With a distcc build /tmp goes to ~78G, of which ~65G is solely build.log. And it hangs for a VERY long time at the end for some reason. 1) I have not figured out how to do the package.env workaround, yet. 2) Or better fix this in chromium.ebuild directly? 3) Maybe try distcc 3.4-r6 unstable instead of current 3.4-r4 stable?
> 1) I have not figured out how to do the package.env workaround, yet. Jörn Valentin described it in comment 21. Create a file /etc/portage/env/nognu (for example) with: CFLAGS="$CFLAGS -Wno-gnu-line-marker" CXXFLAGS="$CXXFLAGS -Wno-gnu-line-marker" and add: www-client/chromium nognu to your package.env > 3) Maybe try distcc 3.4-r6 unstable instead of current 3.4-r4 stable? I use newest - no difference.
Thank you Jan for the idiot(=me)-proof description. I can report I was able to build chromium 133.xx.126 with distcc, sane build time and tmp space size again.
