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: