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

[phoronix]

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

With the release of LibreOffice 7.0 in a few months, the open-source office suite will now prefer building at least portions of its code-base with the LLVM Clang compiler over GCC or Microsoft MSVC even if the default compiler is not Clang...

http://www.phoronix.com/scan.php?page=news_item&px=LibreOffice-7.0-Prefers-Clang

[Danny3]

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.

[kokoko3k]

Maybe i did not understood well what you wrote, but my impression is that thete are zero informations in your post.

[ms178]

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.

[grigi]

There was a blog post about firefox and gcc, and if you disabled the custom clang inline assembly, GCC 10 outperformed clang by a large margin in both performance, and binary size.

[skeevy420]

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.

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".

[Aryma]

i hope if they improve compatibility with right to left language like Hebrew and arabic instead of this compiler BS

[Volta]

i hope if they improve compatibility with right to left language like Hebrew and arabic instead of this compiler BS

I heard they'll improve Arabic and hebrew, but currently they have more important things to do instead of this BS.

[pracedru]

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

[Reiver]

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

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.