View previous topic :: View next topic |
Author |
Message |
Pednick n00b
Joined: 19 Nov 2014 Posts: 21
|
Posted: Fri Sep 18, 2015 12:39 am Post subject: |
|
|
It took me about an hour but I use MAKEOPTS="-j8" in my make.conf cause I have an 8 core processor, there's two of those webkits, so about 2 hours. |
|
Back to top |
|
|
m_neutron n00b
Joined: 26 Feb 2007 Posts: 29 Location: south brandenburg /germany
|
Posted: Thu May 26, 2016 11:57 am Post subject: |
|
|
The compile time of that package is just not okay.
Over the years I got used to update my system in the background with a running xfce-Desktop.
(-j4 -O2 AMD FX(tm)-9590)
That package needs above 1h to compile //each version //quite frequently
As somebody wrote before....I shift the update procedure to night times again just because of that thing.
I have to say that the gentoo performance for me is significantly decreased by things like that.
I might be wrong in understanding the process,
but can't just somebody at gentoo take a hammer and require a binary version from upstream??
or what does it take? |
|
Back to top |
|
|
_kopsu_ n00b
Joined: 31 Mar 2003 Posts: 72 Location: Muurame, Finland
|
Posted: Thu May 26, 2016 4:56 pm Post subject: |
|
|
I am frustrated too. My HW isn't that good but everything else (except llvm-9999 and chromium that i compile regulary) compiles in reasonable time..
I wish too that gentoo developers would make -bin ebuild for webkit...
Code: |
My setup is: AMD Phenom(tm) II X4 840 Processor, 8G ram (/var/tmp/portage in ram)
make.conf:
CFLAGS="-march=amdfam10 -O2 -pipe"
MAKEOPTS="-j5 --load-average 75"
genlop -t webkit-gtk
Currently merging 5 out of 11
* net-libs/webkit-gtk-2.4.10-r200
current merge time: 5 hours, 36 minutes and 51 seconds.
ETA: any time now.
|
|
|
Back to top |
|
|
dobbs Tux's lil' helper
Joined: 20 Aug 2005 Posts: 105 Location: Wenatchee, WA
|
Posted: Thu Jun 01, 2017 7:56 am Post subject: |
|
|
You think that's bad?
Code: | 1496194716: >>> emerge (6 of 51) net-libs/webkit-gtk-2.16.2 to /
1496194716: === (6 of 51) Cleaning (net-libs/webkit-gtk-2.16.2::/usr/portage/net-libs/webkit-gtk/webkit-gtk-2.16.2.ebuild)
1496194721: === (6 of 51) Compiling/Merging (net-libs/webkit-gtk-2.16.2::/usr/portage/net-libs/webkit-gtk/webkit-gtk-2.16.2.ebuild)
1496274727: === (6 of 51) Merging (net-libs/webkit-gtk-2.16.2::/usr/portage/net-libs/webkit-gtk/webkit-gtk-2.16.2.ebuild)
1496274744: >>> AUTOCLEAN: net-libs/webkit-gtk:4
1496274744: === Unmerging... (net-libs/webkit-gtk-2.8.5)
1496274756: >>> unmerge success: net-libs/webkit-gtk-2.8.5
1496274769: === (6 of 51) Post-Build Cleaning (net-libs/webkit-gtk-2.16.2::/usr/portage/net-libs/webkit-gtk/webkit-gtk-2.16.2.ebuild)
1496274769: ::: completed emerge (6 of 51) net-libs/webkit-gtk-2.16.2 to /
|
That's 22.24 hours! :D
This is an old 1.67GHz single-core G4 PowerBook. ...which is currently building the other version of webkit-gtk that's always installed. :/ I really need to set up crossdev with distcc.
Edit:
Well hell, I could have sworn that last message was timestamped in 2017. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54244 Location: 56N 3W
|
Posted: Thu Jun 01, 2017 8:05 am Post subject: |
|
|
Code: | Pi3 64bit ~ # genlop -t webkit-gtk
* net-libs/webkit-gtk
Sat Nov 26 18:58:36 2016 >>> net-libs/webkit-gtk-2.14.2
merge time: 1 day, 1 hour, 51 minutes and 43 seconds.
Sun Dec 18 19:35:17 2016 >>> net-libs/webkit-gtk-2.14.2
merge time: 1 day, 24 minutes and 52 seconds.
Wed Dec 28 18:55:55 2016 >>> net-libs/webkit-gtk-2.14.2
merge time: 22 hours, 34 minutes and 47 seconds.
Sun Jan 29 00:00:49 2017 >>> net-libs/webkit-gtk-2.14.3
merge time: 22 hours, 31 minutes and 18 seconds.
Tue Feb 14 03:17:08 2017 >>> net-libs/webkit-gtk-2.14.4
merge time: 1 day, 1 hour, 29 minutes and 14 seconds.
Thu Feb 23 21:58:15 2017 >>> net-libs/webkit-gtk-2.14.5
merge time: 1 day, 1 hour, 27 minutes and 53 seconds.
Fri Apr 21 23:20:53 2017 >>> net-libs/webkit-gtk-2.16.1
merge time: 1 day, 4 hours, 53 minutes and 22 seconds.
Sat May 20 13:01:49 2017 >>> net-libs/webkit-gtk-2.16.2
merge time: 1 day, 2 hours, 2 minutes and 31 seconds.
|
Thats on a Raspberry Pi 3 in 64 bit mode. Distcc says failed to distribute. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
dobbs Tux's lil' helper
Joined: 20 Aug 2005 Posts: 105 Location: Wenatchee, WA
|
Posted: Thu Jun 01, 2017 9:08 am Post subject: |
|
|
NeddySeagoon wrote: | Thats on a Raspberry Pi 3 in 64 bit mode. Distcc says failed to distribute. |
The only thing I can think of is if you forgot to make the wrapper script so distcc knows which platform-tupled executable to call. But you know what you're doing more than I so... dunno. *shrug* |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Thu Jun 01, 2017 11:18 am Post subject: |
|
|
3 build of 2.14.2 neddy, you have a killer patience |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54244 Location: 56N 3W
|
Posted: Thu Jun 01, 2017 2:50 pm Post subject: |
|
|
krinn,
Different gcc and USE flags I expect. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Thu Jun 01, 2017 11:44 pm Post subject: |
|
|
It's not exactly trivial to provide binary packages for something like this. It is VERY different from firefox-bin (and libreoffice-bin). It provides a stable API and ABI set of libraries for other stuff to use, not just some binary to run a single browser. All the deps would have to accept the -bin too somehow, the -bin would have to provide all the stuff necessary to build things against it, etc etc... This is particularly comlicated also due to the many USE flag options, which other packages USE depend upon - while nothing depends on firefox-bin or libreoffice-bin.
So no, we have not seriously considered providing a -bin..
.. I hope Neddy is busy compiling that 2.16.3 with security fixes... _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54244 Location: 56N 3W
|
Posted: Fri Jun 02, 2017 8:48 am Post subject: |
|
|
Leio,
Code: | genlop -t webkit-gtk
* net-libs/webkit-gtk
...
Thu Jun 1 17:49:39 2017 >>> net-libs/webkit-gtk-2.16.3
merge time: 1 day, 3 hours, 22 minutes and 25 seconds. |
That's a yes. arm64 and gcc-7.1.0 _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Slated n00b
Joined: 16 Oct 2010 Posts: 13
|
Posted: Thu Aug 17, 2017 4:39 pm Post subject: It's 2017 and... |
|
|
Previous build was 22 hours, 49 minutes and 54 seconds on an Atom N450.
This build is 14 hours, 48 minutes and 47 seconds so far, with an ETA that's allegedly "any time now", which to me seems like a bug in genlop. Either that or the genlop devs have a very dry sense of humour.
I wonder how much of WebKit is actually needed, and if one day we might see QtBlink instead [Ed. Is this QtWebEngine?], which hopefully might compile a bit faster? _________________ Homer
http://slated.org |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9679 Location: almost Mile High in the USA
|
Posted: Fri Aug 18, 2017 9:05 pm Post subject: |
|
|
I really want to figure out why distcc does not like webkit-gtk.
I have a P4 (64-bit) that I'm trying to build webkit-gtk on, and every file I get:
distcc[21035] (dcc_please_send_email_after_investigation) Warning: remote compilation of '/tmp/portage/net-libs/webkit-gtk-2.16.6/work/webkitgtk-2.16.6/Source/JavaScriptCore/runtime/ProxyObject.cpp' failed, retried locally and got a different result.
SO... I exported the P4's whole disk via NFS. I mounted and chroot that disk with my i7 and for kicks and giggles, enabled distccd on my P4 and had my i7 distcc extra jobs back to the P4 since it was now idle except for nfsd.
Guess what?
Those "failed, retried locally and got a different result" STILL showed up!
My gosh, it's the same compiler, same disk...what the heck is going on.
At least the i7 should be able to complete building much faster alone without distcc help compared to the p4.
Also another issue: despite MAKEOPTS=-j5, webkit-gtk is still is not using all cores in my CPU, I still only see 2 or 3 cc1pluses running and usually 1, sometimes two idle cores (plus all four hyperthread cores are idle)... so perhaps something with webkit-gtk or ninja is going on...
---
Also qtwebkit... 'nuff said... :-(
---
Oh horrors, guess what
Code: | # revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc |
wants to do? Wild guess... :-(
For now I'm sticking with gcc-4.9.4 for a bit longer... _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
hurricane Tux's lil' helper
Joined: 15 Jul 2004 Posts: 107
|
Posted: Sat Oct 28, 2017 4:34 pm Post subject: The problem with this package… |
|
|
The problem with this package, is closed-source-style application monolithism.
Webkit, like and “modern browser” is bascially its own operating system. Aka platform. With all the bells and whistles. And a virtual machine on top of that. So obviously, as a whole, it is huge.
But, sidestepping the inherent software design anti-pattern of the inner-platform effect for a minute, regular operating systems solve this problem through modularization.
Imagine if you had to compile all of Gentoo, every time a single thing changed. That would be insanity. And here it is too.
Webkit has to be split up into packages at least as small as it was done with QT/KDE. Ditto for Firefox, Libreoffice, etc.
But not with all packages bumping their versions at the same time, like in KDE, or you’ll still have the same compile times, and you will still compile loads of the same barely or not changed code over and over for each bump.
That is what need so be changed.
Until then, I can only suggest Code: | echo webkit-gtk >> /etc/portage/packages.mask/cancer | and then patch Webkit out of every package that uses it, via Code: | /etc/portages/patches/ | , or outright ban those packages too.
I’m doing that as we speak, as for me, only Gnucash and Leksah have hard dependencies on it, and I don’t currently use either of them. |
|
Back to top |
|
|
LIsLinuxIsSogood Veteran
Joined: 13 Feb 2016 Posts: 1179
|
Posted: Tue Nov 14, 2017 8:12 am Post subject: |
|
|
Not to throw yet another wrench in there, besides the one from developers saying that it would be nearly impossible to request that they do something to improve the upstream offering (that really would take more of a weapon than a hammer IMHO)...also, since the topic is Web browsing, I recall back in the day having a preference for certain packaged versions of software, like for example Microsoft Windows '98 versus 2000 and that kind of thing. (This was way before my exploration into linux happening more recent). But I mention that because while it does seem like a fair point about other packages, which could depend on this browser (on what version is purely up to the other package developers, of which there are MANY). So, perhaps instead of seeing it as a problem, the simple solution should be just to install it using emerge -1.
Mask the newer versions of the package and there will be no issues other than strict dependencies, of which there shouldn't really be any. I am compiling on a brand new system, right now. Don't know how long it will take, but I can be sure to let everyone know since the fact of that matter is relevant.
(On my laptop...a quad core i3 5th gen @ IDK how fast, but around 2.1 or 2.2 Gigahertz)
Code: | Machine_West% genlop -t webkit-gtk
* net-libs/webkit-gtk
Fri Nov 3 07:32:31 2017 >>> net-libs/webkit-gtk-2.18.2
merge time: 4 hours, 10 minutes and 43 seconds. |
I guess, if I was going to be compiling it for ARM or something tiny like that it would be different, but I don't see a 4 hour package being a problem if it is only getting updated every so often. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|