net-libs/webkit-gtk-2.4.4 fail package of the year

Dragonlord · Guru Joined: 22 Aug 2004 Posts: 446 Location: Switzerland

Stupid webkit is really going on my nerves. Whenever a new version comes out it's a 50% chance the package is FUBAR. Now the drama starts again with 2.4.4 version and this time in double trouble. Why is such an inherently unstable and buggy package part of portage in the first place?

For the records, installed:
sys-devel/clang-3.3-r100:0/3.3
[1] x86_64-pc-linux-gnu-4.7.3 *
[2] x86_64-pc-linux-gnu-4.8.3

Webkit Fail:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

jburns · Posted: Sun Nov 09, 2014 5:51 am Post subject:

News item "GCC 4.7 Introduced the New C++11 ABI" explains the problem you are seeing with net-libs/webkit-gtk.

Dragonlord · Guru Joined: 22 Aug 2004 Posts: 446 Location: Switzerland

According to Hu it's not a problem:

jburns · Posted: Mon Nov 10, 2014 3:46 am Post subject:

The best way to fix the problem is to configure the latest version of gcc that is installed. If you do not want to use the latest version of gcc then mask it and unmerge it. If you do not want to remove the latest version of gcc then see net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'

Dragonlord · Guru Joined: 22 Aug 2004 Posts: 446 Location: Switzerland

I solved it now by removing webkit and blasting to piece with an 8-ball every crap application daring to pull in 'hard' webkit in one way or the other.

Problem solved but that can't be the way to solve problems of a single ill-behaving package by forcing crap into users. Other libs like FOX god damn it do not get upgraded to 1.7 although it's there like fucking 3 or more years but an ape-shit lib like webkit producing nothing but problems and not compiling in over 50% of release gets arse-licked all over the place. Seriously I'm pissed about how this situation is handled. The problem should be fixed by masking webkit and threatening to remove it from portage if it doesn't start to well-behave not bum-rape users by dropping ticking time-bombs on them waiting until they blow up on the chain. Gentoo really lost in terms of quality and portage handling great this. That's not a situation, that's FUBAR U_U.
_________________
DragonDreams: Leader and Head Programmer

steveL · Posted: Mon Nov 10, 2014 8:40 pm Post subject:

Thistled · Guru Joined: 06 Jan 2011 Posts: 572 Location: Scotland

Ok so lets see if I am getting my stupid thick head around this.
If I want to use chromium or webkit-gtk (which is needed by GNOME apps such as evolution (which is now f@@@ing broken))
I need to change my CXX flags to reflect -std=c++11
But

jburns · Posted: Fri Dec 12, 2014 4:16 am Post subject:

You should not change the CXX flags to reflect -std=c++11. The packages www-client/chromium and net-libs/webkit-gtk change the option when they are building the package.

The problems that I know about are
1. The net-libs/webkit-gtk build will hang if nvidia-drivers is providing the OpenGL implementation and sandbox is being used
2. There is a mismatch between GCC and the library that is used to support c++11. "gcc-config" changes the version of GCC being used but does not change the library.

Thistled · Guru Joined: 06 Jan 2011 Posts: 572 Location: Scotland

Thistled · Guru Joined: 06 Jan 2011 Posts: 572 Location: Scotland

Many thanks jburns for the tip.

Webkit-gtk-2.4.4-r201 finally built with

John R. Graham · Posted: Fri Dec 12, 2014 5:02 pm Post subject:

jburns · Posted: Fri Dec 12, 2014 7:31 pm Post subject:

To clearify when I said

Thistled · Guru Joined: 06 Jan 2011 Posts: 572 Location: Scotland

jcc3 · n00b Joined: 25 Mar 2008 Posts: 18

I also hit this, but with a twist...

in my case, even Thistled's response was not a workaround. That is, failure here, even USE-ing "-sandbox" AND the OpenGL xorg-x11selection made.

Bug reports have pointed out multiple problems. One group of reports is webkit-gtk package build falling over, on one or another build error.

The other is my situation, which is a *loop* during the build -- more precisely (btw the arch is x86, Core 2 Quad in 32-bit mode),

-- an apparently infinite, enabled, non-kernel mode loop, in or under the top-level make(1) process of the build. Some others likely reported the same thing as a "hang."

-- The build log proceeded normally until it just stopped being updated. No errors or warnings evident anywhere.

-- top(1) showed one core mostly at 100% CPU (but fluctuating); however the whole system was not "wedged" -- the rest of the system ran normally, so this was not a disabled loop. Thus I concluded that we were *not*, for example, in a disabled loop in kernel mode, the latter being a very good way to have a whole system "wedge."

-- The system continued in all other respects normally.

-- I finally kill -9'ed the make, and the system still continued normally (with the affected core now added back for useful work)

I had hit this earlier this year (as have some other posters), and at that time I got out of it by simply "jiggling" packages (meaning helter skelter one-shot re-emerges until webkit-gtk built).

The better response would be for me to have attached to the looping make(1) PID with gdb(1), or truss(1)'ed it, or both, and poked around carefully, but the wallclock time wasn't available, so I just ripped webkit-gtk and all its depend roots out of the system, and worked it back down to a clean revdep-rebuild, etc. I don't need webkit* anyway.

This is a classical bug case, worthy of remembering. I have been admin-ing and developing with Gentoo since Larry the Cow first represented Gentoo on the Net, but I have not seen a pkg build bug quite as interesting as this. Enabled loops are notoriously hard to shoot, because unless you have in hand a full running system state, you never really know if you just wait 10 seconds longer, the offending process or thread might terminate normally.

Lesson for me to take away: don't just gratuitously emerge packages -- think about what you need and just include that. Otherwise you are just paying for higher system complexity for no useful benefit.

Speaking On Background

My approach would not be to lay /blame/ on Gentoo or the upstream or ... or ...

I think this is a byproduct of our time. Byproduct of our time?

In the (many would say darker) decades of the closed-everything computing yesterday (I was there), the same vendor that made the sink also made the garbage disposer. You only had one or two choices for the disposer, but interfacing it to the sink was Really Easy. One or two degrees of freedom. Far enough back, you had ONE choice for your net, AT&T.

Fast forward 30-ish years and here we are in OS utopia compared to that, with tons of Open Software that seeks to support all available combinations of brews on (nearly) all combinations of h/w, and so, here we are also with /many/ degrees of freedom.

To support rapidly increasing DoF necessarily brings increasing bug likelihood, no matter how careful we are at engineering new code. Like all freedom, this Open freedom comes with a price, and I stay here because I've agreed to pay it.