Fedora 33 Proposal To Allow Packages To Build With LLVM Clang Rather Than Requiring GCC

[wizard69]

I can see this becoming a slippery slope towards incompatibility.

If it is not Red Hat/Fedora making sure software remains compatible with GCC, chances are in very short order it will stop being the case for the web browser engines.

Why should anyone go out of their way to support a specific compiler? I don't mind if Fedroa is a "GCC based distro, I just don't want the software library limited because somebody has a stick up their but over CLang. I would hope that developers chose the best solution for their products.

Beyond that we as a community have navigates all sorts of compatibility issues due to changing support. Python2 is now more or less dead replaced with Python3. Modern C++ is a far cry from the old versions and some would say worse off. Lets not even get into all the various desktop environments and the tool kits to support them. Incompatibility is something you work through.

[rene]

well, in #t2sde we can long build the whole Linux distribution w/ LLVM/clang though ;-) https://www.youtube.com/watch?v=_kQ3Q_yzzTQ

[andyprough]

Why is GCC compatibility so important? As long as it compiles on a shipping compiler it should be fine. Why should developers contort themselves making GCC work? Code moves in, GCC can either come to the plate or cede the territory.

It's not a problem at all. This sounds like a completely made up issue by someone at RedHat. If you want and if you get your rust tools set up, you can build Firefox just fine on gcc right this second. Upstream is not avoiding gcc, that's just silly nonsense. Building Firefox on gcc is one of the easier build projects you can do. And building chromium sucks not because of gcc, but because Google makes it ridiculously complex intentionally in order to retain as much control over the project as possible. Once again, has nothing to do with gcc. It's ridiculously hard no matter how you try to do it, on purpose.

[jrch2k8]

Well, i get this is about when upstream prefer certain compiler over other and not a global change but they should be very careful because Clang have Internetz fame but is not as trustworthy as GCC is for something so low level in the toolchain.

1.) Clang hate to be updated, clench all you want but i dare you to prove me wrong, i've had entire gentoo system completely break down into unusable simply by upgrading clang(missing symbols, broken deps, llvm going haywire, missing or wrong instructions, libc++ ABI breakage, and so on)

2.) Clang can go full retard very fast and without warnings to the point i rarely build any of my projects on clang anymore unless Mac compatibility is a hard requirement, i do specially love how Clang ASAN with libc++ and lld can make you racket your brain for days tracking a leak that turns out didn't exist(yeah bad bad me, always check that gcc report it as well) and find 2 releases later was a known bug but is not present on apple's version(which answered my old question of why APPLE don't use clang official releases).

3.) Clang support for newer standard is iffy at best compared to GCC, sure GCC may be slower at adopting them but when they do they usually work properly while Clang "support it fasterzzz" but your binary tend to behave erratically or randomly stops compilation(this one give weeks of pure joy a while ago)

I'm not saying clang doesn't have its good side, specially on the tooling side(i do use those all the time) but as a compiler has a lot less QA on releases than GCC does and most of that "SPPEEEDZZZZ" is gone this days compared to modern GCC and for something as low level as as a distro can be a real sources of infinite headaches.

Before someone comes and say GCC is the same, i do use ArchLinux(same apply for my gentoo systems) and i update GCC and the whole toolchain every release and never had breaks that bad, in that sense the team put a real effort in don't break code compiled with previous GCC versions.

[oleid]

One of the advantages of using clang for building Firefox is the possibility of doing cross language LTO as described here:

(LLVM Project Blog: Closing the gap: cross-language LTO between Rust and C/C++)

[lowflyer]

If a software project compiles with one compiler and has problems compiling with another compiler... The only correct conclusion to draw is: there is a problem with that code-base. That's what standards try to solve. But if they don't adhere to the standards, don't expect any other result! Bugs should be fixed where the bugs are.

[wagner17]

"Using GCC to build Firefox can at times lead to build problems given Mozilla's Clang focus and reportedly also in some instances less than ideal performance." I've built Firefox using GCC more times than I can count, and I find this statement a little hard to believe. The problems are always with Rust and with the rust tools getting out of date or getting their sym links out of whack, not with GCC. Firefox built locally with GCC always out-performs distro binaries. It could be that a locally built Clang version would out-perform a GCC build, but I'd have to see some testing.

That was probably true last year when this was done: https://mastransky.wordpress.com/201...-with-pgo-lto/
But may no longer be true because of this: https://bugzilla.mozilla.org/show_bug.cgi?id=1601903
I suspect the fact no one is working on the bug is probably one reason for this change in Fedora policy.

I just did a quick test of the stock Mozilla binaries vs Fedora one and the Mozilla clang build was faster.

[Guest]

Ah how far we've come, from GCCisms to Clangisms.

[jabl]

Wasn't there something with libreoffice as well? Skia(?) uses/used(?) some clang specific asm construct and switched to some dogslow fallback if using anything but clang?

[Sonadow]

Wasn't there something with libreoffice as well? Skia(?) uses/used(?) some clang specific asm construct and switched to some dogslow fallback if using anything but clang?

Speaking of Libreoffice, I have never been able to build LO with Clang even though Clang is officially supported and preferred.

The ./autogen.sh always fails when I specify CC=/path/to/clang CXX=/path/to/clang++ with an error about not supporting C++17. This is on LLVM + Clang 9.

Anyone knows why this is so?