Created attachment 510380 [details] build.log #error "Building release without compiler optimizations: WebKit will be slow. Set -DRELEASE_WITHOUT_OPTIMIZATIONS if this is intended." ^~~~~ ninja: build stopped: subcommand failed. Things I've tried: - recompiled ninja - switched back to gcc-6.4.0 (same error as 7.2.0)
Created attachment 510406 [details] emerge --info
You don't have any -O flags in your CFLAGS and CXXFLAGS (latter is usually set to CXXFLAGS="${CFLAGS}" in make.conf). This results in everything you compile to be not optimized, so your whole Gentoo system is completely unoptimized compilation. Unlike most things, webkit-gtk has a check against this and tells you you are doing something bad, as ZERO optimizations is going to be really bad. Use at least -O1, but -O2 is rather standard. -Os is another option if really needed. I don't think we should be doing any changes here to the package (like putting in an -O2 if none exist), as this point to a big problem to the whole system and I consider it a good thing that at least webkit-gtk points it out.
I have this same problem with webkit-gtk-2.18.6. The #error message is irrelevant, as my CFLAGS include -O2 and I do not receive the message -- but I still receive the message about ninja failing. I will upload my build log.
Created attachment 517002 [details] Build log (gzipped)
(In reply to David W Noon from comment #3) > I have this same problem with webkit-gtk-2.18.6. The #error message is > irrelevant, as my CFLAGS include -O2 and I do not receive the message -- but > I still receive the message about ninja failing. I will upload my build log. doesn't mean you don't have to show emerge --info. But I bet you just ran out of memory, see an OOM killer in action when you look at dmesg and should lower your -j<amount of jobs in parallel> value for webkit-gtk.
(In reply to Mart Raudsepp from comment #5) > (In reply to David W Noon from comment #3) > > I have this same problem with webkit-gtk-2.18.6. The #error message is > > irrelevant, as my CFLAGS include -O2 and I do not receive the message -- but > > I still receive the message about ninja failing. I will upload my build log. > > doesn't mean you don't have to show emerge --info. On its way. > But I bet you just ran out of memory, see an OOM killer in action when you > look at dmesg and should lower your -j<amount of jobs in parallel> value for > webkit-gtk. That is a bet you will definitley lose. I can upload dmesg if you want, but there are no OOM killer logs in it. Moreover, I already use -j1 in make.conf.
Created attachment 517004 [details] emerge --info
(In reply to David W Noon from comment #6) > That is a bet you will definitley lose. I can upload dmesg if you want, but > there are no OOM killer logs in it. Moreover, I already use -j1 in make.conf. Good thing I didn't bet anything, but I saw -j5 passed to ninja in your log as ninja -v -j5 -l0, and your emerge --info confirms MAKEOPTS=-j5.
(In reply to Mart Raudsepp from comment #8) > (In reply to David W Noon from comment #6) > > That is a bet you will definitley lose. I can upload dmesg if you want, but > > there are no OOM killer logs in it. Moreover, I already use -j1 in make.conf. > > Good thing I didn't bet anything, but I saw -j5 passed to ninja in your log > as ninja -v -j5 -l0, and your emerge --info confirms MAKEOPTS=-j5. I have EMERGE_DEFAULT_OPTS with --jobs 1, so only a single ebuild runs at any time. The make utility can use up to 5 threads to build; each thread can have multiple processes, because GCC uses multiple processes for each compile/link. I have 34GiB of virtual storage available on this box. The build ran in the early hours of this morning, with nothing else in the system (except systeam daemons, etc.); even the X11 server was stopped, so there was no GUI chewing up memory. I think 34GiB is enough for even a hog like webkit-gtk. [Hence no OOM involved.]
(In reply to David W Noon from comment #9) > (In reply to Mart Raudsepp from comment #8) > > (In reply to David W Noon from comment #6) > > > That is a bet you will definitley lose. I can upload dmesg if you want, but > > > there are no OOM killer logs in it. Moreover, I already use -j1 in make.conf. > > > > Good thing I didn't bet anything, but I saw -j5 passed to ninja in your log > > as ninja -v -j5 -l0, and your emerge --info confirms MAKEOPTS=-j5. > > I have EMERGE_DEFAULT_OPTS with --jobs 1, so only a single ebuild runs at > any time. The make utility can use up to 5 threads to build; each thread can > have multiple processes, because GCC uses multiple processes for each > compile/link. That MAKEOPTS is precisely what can cause issues for webkit-gtk (and chromium, etc) builds. Not running in parallel via --jobs with some tiny other thing (unless the other thing is huge chromium or so in parallel with webkit-gtk). > I have 34GiB of virtual storage available on this box. The > build ran in the early hours of this morning, with nothing else in the > system (except systeam daemons, etc.); even the X11 server was stopped, so > there was no GUI chewing up memory. > > I think 34GiB is enough for even a hog like webkit-gtk. [Hence no OOM > involved.] No, it's not just about the virtual memory available necessarily. Some compiling and linking stuff can't be swapped out properly and even with plenty of swap available things will fail with too high -j in MAKEOPTS. I've seen plenty of reports with high -j but huge swap that still fail (e.g last case I remember was -j9 and 4GB RAM available with lots of swap, you have rather similar here percent-wise with -j5 and 2GB RAM) That said, maybe you have a different issue, but that's all I can guess given the random build stopped output.
(In reply to Mart Raudsepp from comment #10) > That said, maybe you have a different issue, but that's all I can guess > given the random build stopped output. Indeed, I looked with an uncomfortable text viewer before; now rechecked and found your issue. Check what bottom of dmesg says (if not OOM, I'd still expect a segfault message there) and file a new separate bug, as this isn't the missing -O issue. In file included from /usr/lib/gcc/i686-pc-linux-gnu/6.4.0/include/g++-v6/memory:81:0, from /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WTF/wtf/StdLibExtras.h:31, from /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WTF/wtf/FastMalloc.h:26, from /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WebCore/config.h:62, from /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WebCore/style/StyleSharingResolver.cpp:26: /usr/lib/gcc/i686-pc-linux-gnu/6.4.0/include/g++-v6/bits/unique_ptr.h: In instantiation of 'std::unique_ptr<_Tp, _Dp>::unique_ptr(std::unique_ptr<_Tp, _Dp>&&) [with _Tp = WTF:: Function<void(WebCore::ScriptExecutionContext&)>::CallableWrapper<WebCore::ScriptExecutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr<Inspector::Conso leMessage>&&)::<lambda(WebCore::ScriptExecutionContext&)> >; _Dp = std::default_delete<WTF::Function<void(WebCore::ScriptExecutionContext&)>::CallableWrapper<WebCore::ScriptExe cutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr<Inspector::ConsoleMessage>&&)::<lambda(WebCore::ScriptExecutionContext&)> > >]': /usr/lib/gcc/i686-pc-linux-gnu/6.4.0/include/g++-v6/bits/unique_ptr.h:791:69: required from 'typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with _Tp = WTF::Function<void(WebCore::ScriptExecutionContext&)>::CallableWrapper<WebCore::ScriptExecutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr<Insp ector::ConsoleMessage>&&)::<lambda(WebCore::ScriptExecutionContext&)> >; _Args = {WebCore::ScriptExecutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr< Inspector::ConsoleMessage>&&)::<lambda(WebCore::ScriptExecutionContext&)>}; typename std::_MakeUniq<_Tp>::__single_object = std::unique_ptr<WTF::Function<void(WebCore::ScriptEx ecutionContext&)>::CallableWrapper<WebCore::ScriptExecutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr<Inspector::ConsoleMessage>&&)::<lambda(WebCore: :ScriptExecutionContext&)> >, std::default_delete<WTF::Function<void(WebCore::ScriptExecutionContext&)>::CallableWrapper<WebCore::ScriptExecutionContext::AddConsoleMessageTask: :AddConsoleMessageTask(std::unique_ptr<Inspector::ConsoleMessage>&&)::<lambda(WebCore::ScriptExecutionContext&)> > > >]' /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WTF/wtf/Function.h:43:76: required from 'WTF::Function<Out(In ...)>::Function(CallableType&&) [with C allableType = WebCore::ScriptExecutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr<Inspector::ConsoleMessage>&&)::<lambda(WebCore::ScriptExecutionConte xt&)>; <template-parameter-2-2> = void; Out = void; In = {WebCore::ScriptExecutionContext&}]' /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WebCore/dom/ScriptExecutionContext.h:155:36: required from 'WebCore::ScriptExecutionContext::Task::Ta sk(T) [with T = WebCore::ScriptExecutionContext::AddConsoleMessageTask::AddConsoleMessageTask(std::unique_ptr<Inspector::ConsoleMessage>&&)::<lambda(WebCore::ScriptExecutionCon text&)>; <template-parameter-1-2> = void]' /var/tmp/portage/net-libs/webkit-gtk-2.18.6/work/webkitgtk-2.18.6/Source/WebCore/dom/ScriptExecutionContext.h:234:14: required from here /usr/lib/gcc/i686-pc-linux-gnu/6.4.0/include/g++-v6/bits/unique_ptr.h:210:78: internal compiler error: Segmentation fault : _M_t(__u.release(), std::forward<deleter_type>(__u.get_deleter())) { } ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.gentoo.org/> for instructions.
Thanks for that hint. I have this laptop now for more than 2 years and didn't notice this point for all the time. Including -O2 -pipe did it. webkit-gtk-2.18.6 compiled fine. So in my case we can close this issue as invalid. Not sure, if this issue could help in any other way. Thanks a log.
*** Bug 734026 has been marked as a duplicate of this bug. ***
Can't we append -DRELEASE_WITHOUT_OPTIMIZATIONS to CXXFLAGS to fix this? While building without optimizations is usually dumb, it's widely accepted now that Gentoo packages should respect the user's CFLAGS. There's no technical reason for the restriction in this case if you want to make your browser slow.
(In reply to Michael Orlitzky from comment #14) > Can't we append -DRELEASE_WITHOUT_OPTIMIZATIONS to CXXFLAGS edit: CPPFLAGS
(In reply to Michael Orlitzky from comment #14) > Can't we append -DRELEASE_WITHOUT_OPTIMIZATIONS to CXXFLAGS to fix this? > While building without optimizations is usually dumb, it's widely accepted > now that Gentoo packages should respect the user's CFLAGS. There's no > technical reason for the restriction in this case if you want to make your > browser slow. The counterargument to this is that we fairly often get support issues where users get a build failure and it turns out their make.conf had a typo so their CFLAGS are empty. But yes, we could add a warning or something and proceed anyway.
I don't see a reason to go against upstream here. Not optimized builds are not supported and we are not able to take over support cases of such builds.
What might be good is an earlier error in pkg_pretend if source builds though?
(In reply to Mart Raudsepp from comment #17) > I don't see a reason to go against upstream here. Not optimized builds are > not supported and we are not able to take over support cases of such builds. I don't think it's unsupported -- there's a build flag to allow it. I've had upstream tell me to build with -O0 before. Upstream is thinking in terms of binary packages and flatpaks. If you're building a package for 100,000 other people, it's a mistake to do it without optimization. If you're doing it for one person (yourself) on a distro whose main selling points include respecting your CFLAGS, it might still not be wise, but it's not necessarily a mistake. Empty CFLAGS fall into the same category. Maybe worth a warning, but sometimes that's what you want, and I don't see why webkit-gtk is worthy of a special case.
To me it does not build with -O1. -O2 seems good
