December usually is a busy month, with the focus at work to wrap up as much of the ongoing projects as possible and prepare for the christmas holidays. And when there’s a lot of (paid) work to do, the voluntary work gets second place. That’s why there was not really a lot of time to churn out a Chromium 63 SlackBuild script. Two weeks ago the first sources for release 63 appeared online and fixed a lot of (security) bugs. Last week saw an update and this is what I grabbed and packaged, because you can’t wait too long with addressing security issues.
Those of you who had examined my chromium-dev.SlackBuild a while ago will already know that the SlackBuild for versions beyond 63 needed a bit of re-work to cope with changes at the source level. I am glad I did that in November, as it made the transition for the stable browser much easier.
Starting with this package, I am no longer compiling (P)NaCL by default. NaCL, or the Native Client, is a way to run applications in a sandboxed browser process at near-native speed. The PNaCL binaries are platform-independent which means one executable (.pexe) can run in Chrome/Chromium browsers on all supported platforms/architectures. Google announced in May 2017 that it would stop supporting NaCL in the first quarter of 2018 in favor of WebAssembly which is a new cross-platform cross-browser solution to run high-performance applications. Both Mozilla’s and Google’s browsers already support WebAssembly, Microsoft and Apple are getting there too. You can experience an impressive WebAssembly demo here: The Zen Garden based on Epic’s Unreal Engine.
You can of course recompile the chromium package if you need NaCL. The chromium.SlackBuild script defines a variable “USE_NACL” which used to be set to “1” and now defaults to “0”. If you set it back to “1” and run the SlackBuild script, you will get your NaCL support back.
The reason that I stopped compiling NaCL support is pretty basic.
Last month it became clear to me that many Google developers are not caring about anything else than their own ecosystem. Call me naïve. The compilation issues I was experiencing with the GCC compiler were dissed with a remark that internally, Google uses a patched version of Clang which does what they need and standards-based code is not really at the top of their list. Any issues I had with gcc (along with packagers of other distros), they were not going to fix. The anticipated but unhelpful answer was to just download and use Google’s Clang binaries. But that goes completely against the idea behind my own chromium package… do not rely on the Google binaries (aka Chrome) and instead build natively on Slackware.
It forced me to find a way to compile the Chromium sources using their ‘Google hack’ of the Clang compiler.
So when helpful people at Google (they too exist of course… not all of them are so single-minded) showed me how to download the Google Clang sources, compile that first and then use those binaries to compile Chromium in turn, it dawned on me.
All this time I had been downloading and using Google binaries anyway: the (P)NaCl code is compiled using a pnacl binary toolchain which gets downloaded from Google during the compilation of the Chromium sources. That was the moment where I took the decision to stop with providing NaCL support in my package, and make sure that all the binaries I need for the chromium package are compiled natively on Slackware.
Get chromium 63 packages for Slackware 14.2 and -current:
- http://www.slackware.com/~alien/slackbuilds/chromium/
- https://slackware.nl/people/alien/slackbuilds/chromium (rsync via rsync://slackware.nl/mirrors/people/alien/slackbuilds/chromium/)
Can’t get chromium 63 to work with EpicZenGarden 🙁
it says it doesn’t support WebGL 1
same thing with Firefox 57.0.1
Willy, it works here without any issue. Lenovo T460, HD Graphics 520 (using i915 kernel module).
In chrome://settings/system make sure that “Use hardware acceleration when available” is enabled.
Work, also, here 😉
Yesterday I have built Chromium using chromium.SlackBuild. Only one additional patch is needed: in file third_party/webrtc/p2p/base/port.h we have to add one line: #include .
Thanks a lot to Alien!
in file third_party/webrtc/p2p/base/port.h we have to add one line:
#include <cmath>
Sweet, thanks for your hard work :3
Andrey, on what version and architecture of Slackware are you compiling and getting this webrtc related error?
Zen Garden worked OK here. FF 57.0.2, Slackware64-14.2. Zotac GTX 1050Ti. NVidia 384.90.
Impressive!
I have built chromium on Slackware64-current (x86_64) which I download at 20th of March 2017 (with gcc-5.4.0). But I have installed a lot of additional packages (ftp://ftp.radix.pro/slackware/slackware64-14.2-20170320/additional-packages/) including latest mozilla-nss from Slackware64-current (two days ago). Also I think omitted line with #include <cmath> is a common mistake of Google sources. I can send the patch to you.
Eric,
By the way I would like to say thanks a lot for you. I use Slackware from 1995 and only with your compat32 packages. Your system the best because I can to be owner of my machines instead of to be user.
Best Regards,
Andrey K.
Just installed Chrome. Zen Garden working OK, same setup as above. House full of blue butterflies.
Andrey indeed Slackware-current needs that patch. I built the packages on 14.2 which does not have that issue.
A proper patch has been added to the chromium.SlackBuild now. Thanks for mentioning it because when I looked at the Gentoo patch it looked like it was not relevant to Slackware.
Seems it is fails .
http://oi67.tinypic.com/2jew75w.jpg
Still works but grinds system down to a hault on my slower machine.
Firefox works great.
SLK64 current x86_64 AMD Phenom(tm) II X4 840 Processor AuthenticAMD GNU/Linux
Version 63.0.3239.108 (Developer Build) (64-bit)
drakeo I got the same error but the demo works fine otherwise.