Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
by Steven Munroe
I would also add that Clang/LLVM is missing some of the newer C
language revisions at least for the pppc64le target.
Both IEEE/ISO _Float128 and _Decimalxx support is missing. Ie the
type is not supported or if supported basic arithmetic and math.h
support is missing. Also finding bugs for in-line assembly and missing
constraints needed to work around the missing language features.
Also Clang's poor support for constant folding makes using __int128
(and vector __int128) harder than it needs to be.
This is a significant impact for enabling my project (PVECLIB) for
Clang. As-is a number of project features have been disabled for
Clang.
I think Clang needs more time to cook.
3 years, 11 months
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
Change
by Jeff Law
On Fri, 2020-06-05 at 10:51 +0000, devel-request(a)lists.fedoraproject.org wrote:
>
> Date: Fri, 5 Jun 2020 12:42:30 +0200
> From: Vitaly Zaitsev <vitaly(a)easycoding.org>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
> Change
> To: devel(a)lists.fedoraproject.org
> Message-ID: <08a3d005-da6e-248f-4f70-611a05414907(a)easycoding.org>
> Content-Type: text/plain; charset=utf-8
>
> On 04.06.2020 22:30, Ben Cotton wrote:
> > 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.
>
> +1 for this change.
>
> Also RHBZ#1559007 need to be fixed as well. I'm very tired of patching
> Fedora build flags in order to remove unsupported by Clang options.
I don't think Tom (as the LLVM lead within Red Hat) nor I would object to having
a way to do this more cleanly. While Clang/LLVM and GCC agree on many options, I
can certainly envision the need to have toolchain specific flags and ways to
change them.
>
> --
> Sincerely,
> Vitaly Zaitsev (vitaly(a)easycoding.org)
>
> ------------------------------
>
> Date: Fri, 5 Jun 2020 12:46:12 +0200
> From: Vitaly Zaitsev <vitaly(a)easycoding.org>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
> Change
> To: devel(a)lists.fedoraproject.org
> Message-ID: <f66cc6f5-7b21-f5a2-cf04-cdc2b575cf38(a)easycoding.org>
> Content-Type: text/plain; charset=utf-8
>
> On 05.06.2020 09:52, Kevin Kofler wrote:
> > 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.
>
> Clang is much better than GCC nowadays. It has better architecture,
> support lots of optimizations and analyzers.
>
> GCC is a legacy compiler. It should be completely replaced by Clang in
> the nearest future.
I would disagree strongly with both of those statements, but neither your opinion
nor mine on these statements have any relevance to the change proposal.
THe change proposal is simple. Compiler selection should flow from the upstream
project.
Jeff
3 years, 11 months
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
by Jeff Law
On Fri, 2020-06-05 at 10:51 +0000, devel-request(a)lists.fedoraproject.org wrote:
> Send devel mailing list submissions to
>
> Date: Fri, 05 Jun 2020 12:42:03 +0200
> From: Florian Weimer <fweimer(a)redhat.com>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
> Change
> To: Igor Raits <ignatenkobrain(a)fedoraproject.org>
> Cc: Development discussions related to Fedora
> <devel(a)lists.fedoraproject.org>
> Message-ID: <87pnadu744.fsf(a)oldenburg2.str.redhat.com>
> Content-Type: text/plain
>
> * Igor Raits:
>
> > From what I see, GCC supports it on x86, x86_64, s390x, riscv64,
> > ppc64le. So this just does not include ARM / AArch64 from Fedora
> > architectures.
>
> GCC has aarch64 support for stack-clash-protection, but it only works
> well with 64K pages (otherwise detection is not reliable). This is due
> to a choice by the target maintainers I do not understand. At least it
> does not break anything.
Correct.
>
> I don't know the state on armhfp. It used the generic GCC
> implementation in the past, which we considered too buggy to enable.
I don't think anyone ever stepped up to implement stack-clash protection on 32bit
ARM. I couldn't justify spending the time on it when stack-clash hit because
32bit ARM isn't supported by RHEL. And after doing x86, ppc, s390 and aarch64
for GCC I was burnt out as hell.
I expect LLVM 11 should have stack-clash protection for x86, ppc and s390. I'm
working with ARM to find resources to do an AArch64 implementation with the goal
of landing it for LLVM 12.
jeff
3 years, 11 months
Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
by Jeff Law
On Fri, 2020-06-05 at 14:38 +0000, devel-request(a)lists.fedoraproject.org wrote:
>
> Date: Fri, 5 Jun 2020 15:23:57 +0100
> From: "Richard W.M. Jones" <rjones(a)redhat.com>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
> Change
> To: Development discussions related to Fedora
> <devel(a)lists.fedoraproject.org>
> Cc: Vitaly Zaitsev <vitaly(a)easycoding.org>
> Message-ID: <20200605142357.GQ15536(a)redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Jun 05, 2020 at 08:27:13AM -0400, Neal Gompa wrote:
> > On Fri, Jun 5, 2020 at 8:26 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> > > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel
> > > <devel(a)lists.fedoraproject.org> wrote:
> > > > On 05.06.2020 09:52, Kevin Kofler wrote:
> > > > > 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.
> > > >
> > > > Clang is much better than GCC nowadays. It has better architecture,
> > > > support lots of optimizations and analyzers.
> > > >
> > > > GCC is a legacy compiler. It should be completely replaced by Clang in
> > > > the nearest future.
> > > >
> > >
> > > Having worked in a distribution that uses Clang by default
> > > (OpenMandriva), I can say that this is *not true*. Switching from GCC
> > > to Clang cost OpenMandriva a lot of performance. It also cost them a lot of
> > > security hardening at the compiler level. GCC-built binaries are still
> > > better, and remain better as long as people are continually using and
> > > developing for it.
> > >
> > > This change appears to largely be driven by the maintainers of web
> > > browser packages that upstream have no GCC validation and it has to be
> > > done in Fedora downstream. I know Chromium is a lost cause (Google
> > > couldn't possibly care any less than they do now, especially since
> > > they don't even care about Python 2 being EOL), but has anyone talked
> > > to Mozilla about introducing GCC-based CI for Firefox code? I assume
> > > they have a CI infrastructure that's relatively pluggable.
> > >
> > > Note that having stuff mix compilers is also a bad idea because LTO is
> > > compatible across the two compilers. If you want to use LTO, you need
> > > to use the same compiler across the chain, or stuff will break.
> > >
> >
> > Yay thinkos... I mean that LTO is *not* compatible across the two compilers.
>
> Does this change conflict with:
>
> https://fedoraproject.org/wiki/LTOByDefault
Not it does not.
The LTO bytecode streams do not survive past any given package build. ie, they
are used within the build, then discarded. They're not supposed to show up in
any installed libraries.
Thus the fact that the two compilers use totally different LTO representations
(and always will) is a non-issue here.
Jeff
ps. THe reason we discard the LTO data is because both compilers consider the
LTO bytecodes unstable between major releases.
3 years, 11 months
Re: System-Wide Change proposal: CompilerPolicy Change
by Jeff Law
On Fri, 2020-06-05 at 12:27 +0000, devel-request(a)lists.fedoraproject.org wrote:
>
> On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
> > On 04/06/20 16:30 -0400, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/CompilerPolicy
> > [snip]
> > > == Documentation ==
> > > Several years ago Red Hat's tools team championed for Fedora policy
> > > to strongly
> > > discourage the use of LLVM/Clang for package building. Exceptions
> > > were made for
> > > packages that could only be built with Clang/LLVM:
> > >
> > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler
> > >
> > >
> > > At that point in history Red Hat had no Clang/LLVM engineers or
> > > expertise. In
> > > fact, the LLVM packages were actually maintained by an engineer on
> > > the desktop
> > > team (they had a hard requirement for llvm-pipe, so they got to own
> > > the
> > > Clang/LLVM bits). The policy essentially was a risk management
> > > strategy for
> > > Fedora.
> > >
> > > Times have changed and as a result we should revisit that Fedora
> > > policy.
> > >
> > > The Red Hat tools team believes that LLVM/Clang and GCC should be
> > > considered equals from
> > > a Fedora policy standpoint. Selection of one toolchain over the
> > > should should be
> >
> > s/should should be/other should be/
> >
> > > driven by the upstream project's preferences not by Fedora specific
> > > policy.
> >
> > I think this needs to be clear that we're talking about the compiler
> > here, not the C++ standard library. Fedora has no libc++ expertise
> > I'm
> > aware of.
> >
> > I think we want to be a lot more cautious about using libc++, because
> > it would potentially require large parts of the C++ stack to be built
> > twice and installed in parallel (think Python 2 and Python 3). For
> > example if your package depends on Boost and you want to use libc++
> > then you need Boost rebuilt. Similarly for any C++ library, Qt,
> > gtkmm,
> > etc. etc.
> >
> > And I do not intend to offer C++ support for people who decide to use
> > Clang + libc++ but don't try to resolve their own build failures :)
> >
> >
> > > What that means in practice is that if the project upstream prefers
> > > Clang/LLVM,
> > > then Fedora should in turn be using Clang/LLVM to build those
> > > packages. As a
> > > concrete example, let's consider Chromium.
> > >
> > > Chromium upstream has been building with Clang/LLVM for several
> > > years.
> > > Yet policy
> > > has forced Fedora package owners to shoulder a significant burden
> > > to make it
> > > build with GCC. Furthermore, Fedora does not get as much benefit
> > > at it could by
> > > forcing Chromium to be built with GCC since most other instances
> > > are built with
> > > Clang/LLVM.
> > >
> > > By changing policy Fedora package maintainers no longer have to
> > > waste
> > > time trying
> > > to make Chromium build/work with GCC and Fedora gains additional
> > > "many eyes" and
> > > "many users" benefits by relying on the same tools to build Chrome
> > > as the
> > > upstream developers and other distributions.
> > >
> > > Additionally, if an upstream project currently uses GCC, but
> > > switches to
> > > Clang/LLVM (or vice-versa), then the package in Fedora should
> > > switch
> > > in a similar
> > > manner. The only policy restriction should be that the compiler
> > > must
> > > exist in Fedora.
> >
> > If upstream supports both compilers, that's probably not a good
> > reason
> > to change anything in Fedora.
> >
> > > In some ways this means there is no "default" compiler for Fedora.
> > > The default
> > > is whatever the upstream project supports/recommends. However,
> > > there are
> > > probably many packages with upstreams that are ambivalent about
> > > their compiler
> > > choice. For those packages I would recommend we keep the status
> > > quo at the
> > > current time. For a package with a dead upstream, the Fedora
> > > packager should be
> > > able to select the compiler they want to use for the package.
> >
> > I would prefer the policy to have a stronger preference for GCC when
> > there is no good reason to change. Currently it's worded like keeping
> > the status quo is Jeff's personal opinion. I would like it to be
> > policy.
> >
> > i.e. where the current policy is that you *must* use GCC, unless
> > granted a specific exception, I would like it to be that you *should*
> > use GCC unless there's a good reason not to.
> >
> > "Upstream only builds+tests with Clang and using GCC requires lots of
> > work from the Fedora maintainer to fix problems that upstream don't
> > care about" is a good reason to use Clang.
> >
> > "I've heard the cool kids use Clang, so I changed my package to use
> > it, but I don't know what these compiler errors mean" is not a good
> > reason to switch if it just makes work for other people.
> >
> > When there is a real advantage to using a particular compiler, I do
> > think it's good that packagers should be able to make an informed
> > choice.
>
> Fully agree here, we should be still preferring GCC and not allow
> changing compilers just because it seems cool.
Precisely. I don't believe we should just blindly change compilers for any
project. The change really should be driven by the upstream community. They're
generally in the best position to determine what toolchain best suits their
needs.
If the upstream community for a give package doesn't have a strong preference,
then things should stay as-is. I'd love to see that in any updated policy as
well.
>
> > Ideally we'd have CI building (nearly) everything with *both* GCC and
> > Clang, and finding and fixing problems in packages and in both
> > compilers. But that's probably not realistic (yet?).
>
> Well, building itself is not that interesting but running some
> benchmarks periodically with clang / gcc compiled binaries would be
> interesting. Though this definitely is huge amount of work and we
> should not block this change on this.
Building is certainly interesting as the set of diagnostics you get from the
toolchains is different and I would consider doing so best practice. However, we
don't have a strong policy of addressing diagnostics in Fedora and thus building
with both has little value at this time. I'd like to change that, but it's out
of scope right now.
Benchmarking for performance seems to me like something an upstream project
should be doing as they evaluate their toolchain choices. Ultimately the only
benchmark that matters is your own code ;-)
jeff
>
3 years, 11 months
Re: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change
by Jeff Law
On Fri, 2020-06-05 at 07:33 +0000, devel-request(a)lists.fedoraproject.org wrote:
> ----------------------------------------------------------------------
>
> Date: Fri, 5 Jun 2020 09:16:21 +0200
> From: Frantisek Zatloukal <fzatlouk(a)redhat.com>
> Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy
> Change
> To: Development discussions related to Fedora
> <devel(a)lists.fedoraproject.org>
> Message-ID:
> <CACBV9ZgCJm-5jbaG4myZfByjg6gt7dZoeA26uxcqtzcnrp4G4g(a)mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="00000000000064befd05a7510a78"
>
> --00000000000064befd05a7510a78
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, Jun 5, 2020 at 9:11 AM Igor Raits <ignatenkobrain(a)fedoraproject.org>
> wrote:
>
> > Also we probably should mention that -fstack-clash-protection is not
> > available in clang, so in theory binaries can be less secure due to
> > that.
> >
>
> This seems to be worked on as per https://reviews.llvm.org/D68720?id=224102 (on
> x86, I am not sure on what arches GCC supports -fstack-clash-protection ).
stack-clash-protection is under active development in Clang/LLVM. Serge has done
the x86_64 implementation and engineers from IBM are currently working on
implementations for Power and Z series. I'm also in contact with ARM engineers
to try and get AArch64 covered as well. Realistically I expect Power and Z to
land in LLVM 11 and AArch64 in LLVM 12.
jeff
>
3 years, 11 months
How to convert from GRUB to systemd-boot?
by Richard Shaw
Is there someone that can help me convert my Fedora install from GRUB to
systemd-boot and actually get it where kernel updates won't break it?
The reason is that my MS Surface GO does not work with GRUB for some
reason. Probably a non-standard UEFI implementation but I both found this
to be the case personally and google seem to confirm this. One proposed
solution is to use systemd-boot, which I have semi-successfully done.
Getting to where I can boot the currently installed kernel is
chronicled here:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.o...
If I wasn't using both the internal NVME for "/" and a SD card for
everything else I probably would have just converted the /boot partition to
FAT32 and made it the new ESP partition...
So the last two steps is:
1. See if I can get it working with secure boot enabled.
2. How to make it work with kernel updates which are completely grub
centric.
Side question: If you're booting EFI with GPT partitions, is there any
advantage to using grub over systemd-boot? The latter seems much simpler as
the former seems way more complicated than necessary including the very
fragile environment block[1]
Thanks,
Richard
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1625124
3 years, 11 months
Rebuilt for OpenCV 4.3.0 in rawhide
by Nicolas Chauvet
Hello there,
There is an update to opencv 4.3.0 in preparation for rawhide.
This will be handled in a side tag along with the rebuild of the all
dependencies.
(fedpkg build --target=f33-build-side-24026)
This was evaluated ahead,so it should lead to issue.
https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/builds/
(failures are random issue on copr builders, should be all green on koji).
We will merge the side tag next week and once everything have been rebuilt.
Thanks
--
-
Nicolas (kwizart)
3 years, 11 months