LibreOffice 7.0 Will Prefer Building Its Rendering Code With LLVM's Clang Compiler

[ms178]

Great. Maybe now LibreOffice Impress will be able to do slides transitions on linux without crashing.

Last time I tried Impress, I wasn't impressed at all either. Google's equivalent was way more intuitive and functional for my purposes.

[discordian]

That's because "Do No Evil" Google backs GNU & GPL products right until they have a BSD or MIT replacement where it becomes "G whose-a-what's-it....if you sign up now you'll get an extra 20GB of Drive".

Well, If you want to "Do No Evil", then certainly you don't want to give out copyright assignments to some vile guys from the FSF, that can pull another GPL3 anytime.

[nanonyme]

Anything but Microsoft MSVC.
I don't want to let Microsoft break Windows 7 with spyware and other intentional security vulnerabilities they may have put in their compiler like they have done in the so-called "security updates".
I have no source for this and I haven't searched for any, but If I thought of this, I bet they already have implemented some garbage like this which is pretty hard to notice.
So, in my opinion, open source software should be compiled with open source compiler otherwise even if the source software was open source, it cannot be trusted.
I assume the resulted binary still cannot be verified if it matches exactly the source code to detect if any lines were added, deleted or changed.

To be fair, Microsoft is also eyeing LLVM/clang as a compiler. There's experimental support in new Visual Studio releases.

[andyprough]

Great. Maybe now LibreOffice Impress will be able to do slides transitions on linux without crashing.

Never had that problem, use it weekly on MX. Are you trying to use it on a distro like Ubuntu or Fedora? Those aren't really set up well for office app use.

[Steffo]

It's not so much Skia being only for Clang/LLVM as them not being bothered not to do anything for GCC (which is unfortunately their choice). There was an interesting post from Honza Hubicka benchmarking and optimising Firefox which also uses Skia; https://hubicka.blogspot.com/2018/12...lding-and.html

Thanks, the blog post make it very clear:

A number of routines in Skia’s software backend have been written to run fastest when compiled by Clang. If you depend on software rasterization, image decoding, or color space conversion and compile Skia with GCC, MSVC or another compiler, you will see dramatically worse performance than if you use Clang.
This choice was only a matter of prioritization; there is nothing fundamentally wrong with non-Clang compilers. So if this is a serious issue for you, please let us know on the mailing list.

[wizard69]

It's not so much Skia being only for Clang/LLVM as them not being bothered not to do anything for GCC (which is unfortunately their choice). There was an interesting post from Honza Hubicka benchmarking and optimising Firefox which also uses Skia; https://hubicka.blogspot.com/2018/12...lding-and.html

I'd suggest that the LLVM/CLang community have a better, more open development model, that is driving many organizations to prefer it.

Essentially they couldn't be be bothered to make code using CLANG vector extensions compatible with GCC vector extensions, though both are similar GNU vector extensions but just GCC was less "ergonomic". See the comments at the end from some Skia developers. Unfortunately nothing further seems to come of the authors future work to resolve it.

Why develop a kludge when you can keep focused on one API?

[ssokolow]

I still don't get it that Google on the one hand is behind the efforts to build the Linux kernel with Clang arguing for compiler diversity there (citing all the benefits that come with it) and on the other hand they dropped GCC support on several of their projects, e.g. Chrome/Chromium citing too much of a hassle supporting multiple compilers.

Now these problems trickle down to other projects which need to deal with the fallout such as the LibreOffice crew trying to integrate Skia. It seems Skia was developed with Clang-isms in mind. Developing for several compilers could have prevented this mess.

Google isn't a monolith. You may be looking at the divide between different groups of developers.

[Marc Driftmeyer]

I still don't get it that Google on the one hand is behind the efforts to build the Linux kernel with Clang arguing for compiler diversity there (citing all the benefits that come with it) and on the other hand they dropped GCC support on several of their projects, e.g. Chrome/Chromium citing too much of a hassle supporting multiple compilers.

Now these problems trickle down to other projects which need to deal with the fallout such as the LibreOffice crew trying to integrate Skia. It seems Skia was developed with Clang-isms in mind. Developing for several compilers could have prevented this mess.

Who owns and controls Linux?

[jabl]

It's about power dynamics. Even if we, hypothetically, assume Google has some company wide edict to standardise on clang, for skia they can just do it and tell everyone who disagrees to pound sand. For the the Linux kernel, they have to convince non-google maintainers why adding clang support is worthwhile.

[archsway]

Are they trying to compete with Firefox to see who can be the most slow and bloated?