On Fri, 2020-06-05 at 07:58 +0000, devel-request(a)lists.fedoraproject.org wrote:
Date: Fri, 05 Jun 2020 09:52:09 +0200
From: Kevin Kofler <kevin.kofler(a)chello.at>
Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
Change
To: devel(a)lists.fedoraproject.org
Message-ID: <rbctja$q1r$1(a)ciao.gmane.io>
Content-Type: text/plain; charset="ISO-8859-1"
Ben Cotton wrote:
> == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM. This
> change proposal replaces that policy with one where compiler selection
> for Fedora follows the package's upstream preferences.
>
> == Owner ==
> * Name: Jeff Law
> * Email: law(a)redhat.com
I am opposed to this change. Chromium and Firefox build fine with GCC. I
think that a distribution should be built with a consistent toolchain
wherever possible.
But that's because engineers spend the time to make that
work. It's not a
trivial task. And while there is some value to that work (it exposes non-
portable code in the package or bugs in GCC), I believe Fedora developers' time
is better spent elsewhere.
Last I checked, there were several reasons why GCC is preferred over
Clang/LLVM in Fedora. And if that should ever change (or have changed
already), then switching the systemwide default (reversing the rules, i.e.,
using GCC only for those packages that do not build with Clang) should be
envisioned. But as far as I know, that is not the case at this time,
considering runtime performance, security features, etc.
The reasons GCC was
preferred was because Red Hat's tools team had no Clang/LLVM
expertise and thus had no ability to help address issues that might arise.
Furthermore when the policy was put into place Clang/LLVM was "only" ~10 years
old and the tools team considered it still maturing. It was risk mitigation,
pure and simple.
Red Hat has slowly staffed up in the Clang/LLVM space which addresses the first
problem. And naturally Clang/LLVM has continued to mature addressing the second
problem and it has reached the point where we are comfortable with Clang/LLVM as
a co-equal toolchain. And if I look at development community trajectories I have
no concerns about the viability of Clang/LLVM going forward.
We are not proposing a change in the default compiler. Only to allow the
compiler selection to be driven by the upstream project.
I do not see why we should allow yet another special case for Firefox, nor
why we should let random packages make their own choice of compiler and risk
running into hidden binary incompatibilities. We have a system compiler for
a reason.
This is not a special case for Firefox or any other package. It is
acknowledgment that the toolchains are comparable and each has its own strengths
and weaknesses which in turn may cause an upstream project to prefer one over the
other.
Are the risks, certainly. But that's already the case because packages that are
building with Clang/LLVM (they do exist) have to interoperate with libraries that
are compiled with GCC. Similarly Clang/LLVM has to work with headers that are
supplied by GCC (libstdc++ in particular).
I've been doing GCC compiler development for 30 years and have had the "joy"
of
trying to make GCC compatible with compilers from HP, IBM, Sun, MIPS, as well as
various embedded compilers through the years, often without documentation. The
ABI compatibility situation between Clang/LLVM and GCC is *far* better than any
I've dealt with through the decades and I strongly believe both projects have a
vested interest in maintaining ABI compatibility and fixing ABI bugs.
jeff