Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 641398 - net-libs/webkit-gtk-2.18.3 fails to compile with no -O? optimization in CXXFLAGS (on purpose from upstream)
Summary: net-libs/webkit-gtk-2.18.3 fails to compile with no -O? optimization in CXXFL...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
: 734026 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-16 19:23 UTC by Sven Müller
Modified: 2020-08-15 17:13 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,66.13 KB, text/x-log)
2017-12-16 19:23 UTC, Sven Müller
Details
emerge --info (emerge_infom.txt,7.31 KB, text/plain)
2017-12-16 21:04 UTC, Sven Müller
Details
Build log (gzipped) (net-libs:webkit-gtk-2.18.6:20180128-001338.log.gz,440.61 KB, application/gzip)
2018-01-28 18:18 UTC, David W Noon
Details
emerge --info (emerge_info.txt,7.21 KB, text/plain)
2018-01-28 18:38 UTC, David W Noon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Müller 2017-12-16 19:23:29 UTC
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)
Comment 1 Sven Müller 2017-12-16 21:04:30 UTC
Created attachment 510406 [details]
emerge --info
Comment 2 Mart Raudsepp gentoo-dev 2018-01-11 12:34:45 UTC
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.
Comment 3 David W Noon 2018-01-28 18:11:34 UTC
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.
Comment 4 David W Noon 2018-01-28 18:18:50 UTC
Created attachment 517002 [details]
Build log (gzipped)
Comment 5 Mart Raudsepp gentoo-dev 2018-01-28 18:27:19 UTC
(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.
Comment 6 David W Noon 2018-01-28 18:38:28 UTC
(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.
Comment 7 David W Noon 2018-01-28 18:38:58 UTC
Created attachment 517004 [details]
emerge --info
Comment 8 Mart Raudsepp gentoo-dev 2018-01-28 19:15:06 UTC
(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.
Comment 9 David W Noon 2018-01-28 19:29:54 UTC
(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.]
Comment 10 Mart Raudsepp gentoo-dev 2018-01-28 21:19:45 UTC
(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.
Comment 11 Mart Raudsepp gentoo-dev 2018-01-28 21:27:20 UTC
(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.
Comment 12 Sven Müller 2018-03-19 19:07:18 UTC
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.
Comment 13 Vjaceslavs Klimovs 2020-08-15 17:13:37 UTC
*** Bug 734026 has been marked as a duplicate of this bug. ***