On Fri, 2020-06-05 at 07:58 +0000, devel-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > > Date: Fri, 05 Jun 2020 09:52:09 +0200 > From: Kevin Kofler <kevin.kofler@xxxxxxxxx> > Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy > Change > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > Message-ID: <rbctja$q1r$1@xxxxxxxxxxxxx> > 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@xxxxxxxxxx > > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
