https://fedoraproject.org/wiki/Changes/CompilerPolicy
== 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@redhat.com
== Detailed Description ==
The main goal here is to make selection of the compiler to build a package flow from upstream in an effort to preserve our development resources. In cases where there is no upstream the Fedora package maintainer should be allowed to make the compiler choice for the package. For packages where upstream does not have a strong compiler preference, we should (for now) stick with the status quo to avoid unnecessary churn.
== Benefit to Fedora ==
This change allows packages to be built with whatever compiler the upstream project recommends/supports (so long as that compiler is in Fedora). Thus, Fedora package owners no longer need to spend time making a package work with GCC if the upstream project is using Clang/LLVM.
An obvious example is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time.
Additionally Fedora loses the benefit of the testing provided by other distributions where Firefox is compiled in the same way as the upstream project -- when issues arise the Fedora team must consider the possibility that the problem is due to using GCC instead of Clang/LLVM or the patches to make that possible. Again, this is a poor use of Fedora developer's time.
In the immediate term this change in policy only affects a few packages (Firefox, Chromium and perhaps a few others). The benefit will likely expand over time.
== Scope == * Proposal owners: Update the Fedora Packaging Guidelines to reflect the policy change.
* Other developers: Developers working with packages where upstream builds with Clang/LLVM, but Fedora policy has forced the package to build with GCC should update their packages to build with Clang/LLVM, dropping all Fedora specific changes that were necessary to make the package build with GCC.
Firefox and Chromium are known to be impacted, there may be other packages. While there is no specific timeframe where this would need to be accomplished as the existing packages are already building with GCC, getting the conversion done earlier rather than later seems beneficial. Failure to identify all the impacted packages is not a catastrophic failure, we just fail to reap the benefits in the immediate term.
* Release engineering: [https://pagure.io/releng/issue/9503] (a check of an impact with Release Engineering is needed) I do not believe this change requires any coordination with release engineering. No mass rebuild is required.
* Policies and guidelines: Yes, the packaging guidelines certainly need to be updated for this feature. That can happen as soon as the exact text is agreed upon. Development work on packages such as Firefox or Chrome can happen as soon FESCO agrees to the change while the final packaging guideline text is hammered out.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == This should not require any configuration changes or data migration, nor should it change existing functionality.
== How To Test == For packages where the compiler should change, the package owner will need to update the spec file and build the package with the new compiler. Once done, the package's testsuite should be run (if it's not part of the standard build process).
In general, I would think the standard Fedora QE work should be sufficient here, perhaps with a bit of additional attention to the affected packages. The graphical nature of some of the affected packages like Firefox and Chrome will make testing difficult on some of Fedora's architectures.
== User Experience == Users should not notice any change.
== Dependencies == One the policy change is made a set of packages will need to be updated. Firefox and Chrome are known to be affected. There may be others. It seems like the Fedora package owners are in the best position to know if their package is affected by the policy change.
It is useful to remember that the packages as they exist today still work. Therefore if a package which should change is not identified now, it will continue to work. Similarly if the package owner does not have the time to implement the change right now, the existing package will continue to work.
== Contingency Plan == The backup plan is trivial. We can keep the current policy in place.
If the policy change is approved, but a particular package has not switched to the upstream preferred compiler, the package can continue to build with GCC until the package maintainer has the time to make the change for their particular package.
Failure to convert any particular package should not create any downstream or distribution wide delays.
* Contingency mechanism: It seems like we could institute the policy change anytime we choose. But it also seems like once the policy change is in place, packages that are going to convert should do so before beta freeze.
* Contingency deadline: Fedora can ship with this feature in an incomplete state. * Blocks release? No * Blocks product? N/A
== 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 driven by the upstream project's preferences not by Fedora specific policy.
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.
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.
== Release Notes == This change should not have any end user impacts nor does it strictly require a release note. However, a short release note could be written if FESCo or the development community thinks it would be useful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== 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.
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
Also does this mean that Clang is now fully supported compiler by full- time working people @ Red Hat in toolchains team that are also contributing to upstream? Just curious if we will be able to "fully support" people when we find bugs in the compiler.
And also, does it mean that we will be following same pattern as with GCC to test pre-release versions in rawhide, do the mass rebuild and so on?
== Owner ==
- Name: Jeff Law
- Email: law@redhat.com
Thanks Jeff for working on this!
== Detailed Description ==
The main goal here is to make selection of the compiler to build a package flow from upstream in an effort to preserve our development resources. In cases where there is no upstream the Fedora package maintainer should be allowed to make the compiler choice for the package. For packages where upstream does not have a strong compiler preference, we should (for now) stick with the status quo to avoid unnecessary churn.
== Benefit to Fedora ==
This change allows packages to be built with whatever compiler the upstream project recommends/supports (so long as that compiler is in Fedora). Thus, Fedora package owners no longer need to spend time making a package work with GCC if the upstream project is using Clang/LLVM.
An obvious example is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time.
Additionally Fedora loses the benefit of the testing provided by other distributions where Firefox is compiled in the same way as the upstream project -- when issues arise the Fedora team must consider the possibility that the problem is due to using GCC instead of Clang/LLVM or the patches to make that possible. Again, this is a poor use of Fedora developer's time.
In the immediate term this change in policy only affects a few packages (Firefox, Chromium and perhaps a few others). The benefit will likely expand over time.
== Scope ==
- Proposal owners:
Update the Fedora Packaging Guidelines to reflect the policy change.
- Other developers:
Developers working with packages where upstream builds with Clang/LLVM, but Fedora policy has forced the package to build with GCC should update their packages to build with Clang/LLVM, dropping all Fedora specific changes that were necessary to make the package build with GCC.
Firefox and Chromium are known to be impacted, there may be other packages. While there is no specific timeframe where this would need to be accomplished as the existing packages are already building with GCC, getting the conversion done earlier rather than later seems beneficial. Failure to identify all the impacted packages is not a catastrophic failure, we just fail to reap the benefits in the immediate term.
- Release engineering: [https://pagure.io/releng/issue/9503] (a check
of an impact with Release Engineering is needed) I do not believe this change requires any coordination with release engineering. No mass rebuild is required.
- Policies and guidelines:
Yes, the packaging guidelines certainly need to be updated for this feature. That can happen as soon as the exact text is agreed upon. Development work on packages such as Firefox or Chrome can happen as soon FESCO agrees to the change while the final packaging guideline text is hammered out.
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == This should not require any configuration changes or data migration, nor should it change existing functionality.
== How To Test == For packages where the compiler should change, the package owner will need to update the spec file and build the package with the new compiler. Once done, the package's testsuite should be run (if it's not part of the standard build process).
In general, I would think the standard Fedora QE work should be sufficient here, perhaps with a bit of additional attention to the affected packages. The graphical nature of some of the affected packages like Firefox and Chrome will make testing difficult on some of Fedora's architectures.
== User Experience == Users should not notice any change.
I think this is not fully true because clang / gcc produce different binaries in terms of size / performance. So just switching compiler in some package may result in significat (hopefully not) performance gain / drop.
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.
== Dependencies == One the policy change is made a set of packages will need to be updated. Firefox and Chrome are known to be affected. There may be others. It seems like the Fedora package owners are in the best position to know if their package is affected by the policy change.
It is useful to remember that the packages as they exist today still work. Therefore if a package which should change is not identified now, it will continue to work. Similarly if the package owner does not have the time to implement the change right now, the existing package will continue to work.
I think this should mention that annobin plugin should be prepared for clang.
== Contingency Plan == The backup plan is trivial. We can keep the current policy in place.
If the policy change is approved, but a particular package has not switched to the upstream preferred compiler, the package can continue to build with GCC until the package maintainer has the time to make the change for their particular package.
Failure to convert any particular package should not create any downstream or distribution wide delays.
- Contingency mechanism:
It seems like we could institute the policy change anytime we choose. But it also seems like once the policy change is in place, packages that are going to convert should do so before beta freeze.
- Contingency deadline: Fedora can ship with this feature in an
incomplete state.
- Blocks release? No
- Blocks product? N/A
== 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 driven by the upstream project's preferences not by Fedora specific policy.
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.
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.
== Release Notes == This change should not have any end user impacts nor does it strictly require a release note. However, a short release note could be written if FESCo or the development community thinks it would be useful.
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org 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-announce@lists.fedorapro...
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Fri, Jun 5, 2020 at 9:11 AM Igor Raits ignatenkobrain@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 ).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 09:16 +0200, Frantisek Zatloukal wrote:
On Fri, Jun 5, 2020 at 9:11 AM Igor Raits < ignatenkobrain@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 ).
Yeah, I think this was mentioned in the https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/89#comment...
- 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.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
* 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.
I don't know the state on armhfp. It used the generic GCC implementation in the past, which we considered too buggy to enable.
Thanks, Florian
On 05/06/20 09:09 +0200, Igor Raits wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== 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.
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
Also does this mean that Clang is now fully supported compiler by full- time working people @ Red Hat in toolchains team that are also contributing to upstream? Just curious if we will be able to "fully support" people when we find bugs in the compiler.
Yes, for Clang and LLVM. Not for the libc++ standard library though.
And also, does it mean that we will be following same pattern as with GCC to test pre-release versions in rawhide, do the mass rebuild and so on?
Good question.
On 06/05/2020 12:09 AM, Igor Raits wrote:
On Thu, 2020-06-04 at 16:30 -0400, 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.
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
Also does this mean that Clang is now fully supported compiler by full- time working people @ Red Hat in toolchains team that are also contributing to upstream? Just curious if we will be able to "fully support" people when we find bugs in the compiler.
And also, does it mean that we will be following same pattern as with GCC to test pre-release versions in rawhide, do the mass rebuild and so on?
We have been packaging -rc1 release candidates of major Clang/LLVM releases in rawhide and plan to continue doing this. It's also possible we could package even early snapshots if this fits better with the Fedora release schedule, but this is not something we have done before.
-Tom
== Owner ==
- Name: Jeff Law
- Email: law@redhat.com
Thanks Jeff for working on this!
== Detailed Description ==
The main goal here is to make selection of the compiler to build a package flow from upstream in an effort to preserve our development resources. In cases where there is no upstream the Fedora package maintainer should be allowed to make the compiler choice for the package. For packages where upstream does not have a strong compiler preference, we should (for now) stick with the status quo to avoid unnecessary churn.
== Benefit to Fedora ==
This change allows packages to be built with whatever compiler the upstream project recommends/supports (so long as that compiler is in Fedora). Thus, Fedora package owners no longer need to spend time making a package work with GCC if the upstream project is using Clang/LLVM.
An obvious example is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time.
Additionally Fedora loses the benefit of the testing provided by other distributions where Firefox is compiled in the same way as the upstream project -- when issues arise the Fedora team must consider the possibility that the problem is due to using GCC instead of Clang/LLVM or the patches to make that possible. Again, this is a poor use of Fedora developer's time.
In the immediate term this change in policy only affects a few packages (Firefox, Chromium and perhaps a few others). The benefit will likely expand over time.
== Scope ==
- Proposal owners:
Update the Fedora Packaging Guidelines to reflect the policy change.
- Other developers:
Developers working with packages where upstream builds with Clang/LLVM, but Fedora policy has forced the package to build with GCC should update their packages to build with Clang/LLVM, dropping all Fedora specific changes that were necessary to make the package build with GCC.
Firefox and Chromium are known to be impacted, there may be other packages. While there is no specific timeframe where this would need to be accomplished as the existing packages are already building with GCC, getting the conversion done earlier rather than later seems beneficial. Failure to identify all the impacted packages is not a catastrophic failure, we just fail to reap the benefits in the immediate term.
- Release engineering: [https://pagure.io/releng/issue/9503] (a check
of an impact with Release Engineering is needed) I do not believe this change requires any coordination with release engineering. No mass rebuild is required.
- Policies and guidelines:
Yes, the packaging guidelines certainly need to be updated for this feature. That can happen as soon as the exact text is agreed upon. Development work on packages such as Firefox or Chrome can happen as soon FESCO agrees to the change while the final packaging guideline text is hammered out.
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == This should not require any configuration changes or data migration, nor should it change existing functionality.
== How To Test == For packages where the compiler should change, the package owner will need to update the spec file and build the package with the new compiler. Once done, the package's testsuite should be run (if it's not part of the standard build process).
In general, I would think the standard Fedora QE work should be sufficient here, perhaps with a bit of additional attention to the affected packages. The graphical nature of some of the affected packages like Firefox and Chrome will make testing difficult on some of Fedora's architectures.
== User Experience == Users should not notice any change.
I think this is not fully true because clang / gcc produce different binaries in terms of size / performance. So just switching compiler in some package may result in significat (hopefully not) performance gain / drop.
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.
== Dependencies == One the policy change is made a set of packages will need to be updated. Firefox and Chrome are known to be affected. There may be others. It seems like the Fedora package owners are in the best position to know if their package is affected by the policy change.
It is useful to remember that the packages as they exist today still work. Therefore if a package which should change is not identified now, it will continue to work. Similarly if the package owner does not have the time to implement the change right now, the existing package will continue to work.
I think this should mention that annobin plugin should be prepared for clang.
== Contingency Plan == The backup plan is trivial. We can keep the current policy in place.
If the policy change is approved, but a particular package has not switched to the upstream preferred compiler, the package can continue to build with GCC until the package maintainer has the time to make the change for their particular package.
Failure to convert any particular package should not create any downstream or distribution wide delays.
- Contingency mechanism:
It seems like we could institute the policy change anytime we choose. But it also seems like once the policy change is in place, packages that are going to convert should do so before beta freeze.
- Contingency deadline: Fedora can ship with this feature in an
incomplete state.
- Blocks release? No
- Blocks product? N/A
== 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 driven by the upstream project's preferences not by Fedora specific policy.
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.
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.
== Release Notes == This change should not have any end user impacts nor does it strictly require a release note. However, a short release note could be written if FESCo or the development community thinks it would be useful.
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org 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-announce@lists.fedorapro...
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: ...
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases.
But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC.
Also does this mean that Clang is now fully supported compiler by full- time working people @ Red Hat in toolchains team that are also contributing to upstream? Just curious if we will be able to "fully support" people when we find bugs in the compiler.
Yes. Absolutely. Tom S & Serge G directly. Others in a more indirect capacity.
And also, does it mean that we will be following same pattern as with GCC to test pre-release versions in rawhide, do the mass rebuild and so on?
Some of that is already happening internally. Tom's got a tester which spins Fedora packages with Clang/LLVM. I'm not sure if he's trying to cover the whole distro, but it is running regularly (it shares a jenkins instance with my tester).
...
I think this is not fully true because clang / gcc produce different binaries in terms of size / performance. So just switching compiler in some package may result in significat (hopefully not) performance gain / drop.
Certainly switching compilers can result in performance changes. Having been through this kind of disruptive change on the other side (GCC vs various vendor compilers through the 90s), what tends to happen is the compilers get to a point where they're typically +-5% of each other on the vast majority of codes. That's where Clang/LLVM and GCC are today based on the data I've seen.
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.
Clang/LLVM is closing that gap rapidly. I fully expect stack clash protection to be at parity on the relevant platforms except aarch64 by LLVM 11 and a reasonable chance to reach parity on aarch64 by LLVM 12.
...
I think this should mention that annobin plugin should be prepared for clang.
Nick Clifton is already working on that :-)
Jeff
On Fri, Jun 05, 2020 at 01:36:37PM -0600, Jeff Law wrote:
On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: ...
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases.
But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC.
Why? Shouldn't the Fedora maintainers be able to decide this? If they have been using GCC for years and it hasn't been an obstackle for them, why should they switch? If I understand the LO case, it is just that LO sometimes uses the Skia library which is written by Google and Google likes compiler monoculture and is using heavily #ifdef __clang__ in it and using the clang variants of the generic vectors guarded by that, and as fallback just doesn't use simd. I believe Honza Hubicka had quite some changes for Skia, not sure if they went upstream already or not. But the maintainers should be able to choose, build just Skia with clang and rest of LO with GCC, or everything with GCC and with help from us get Skia into shape for better portability (that would be ideal, but of course can mean more hopefully one time work), or build all of it with Clang/LLVM.
Jakub
On Fri, 2020-06-05 at 21:49 +0200, Jakub Jelinek wrote:
On Fri, Jun 05, 2020 at 01:36:37PM -0600, Jeff Law wrote:
On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: ...
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases.
But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC.
Why? Shouldn't the Fedora maintainers be able to decide this? If they have been using GCC for years and it hasn't been an obstackle for them, why should they switch?
Maintainers aren't static and when the maintainer chooses to go a different direction than upstream, then there's a cost to be paid. While it may work for a particular maintainer to do something different for their package, what about the poor person who takes the package over when the original maintainer leaves or someone who has to pick it up to deal with a CVE while the maintainer is on PTO.
Not everyone is as toolchain savvy as you, or is able to understand the intent of code as well, or is likely to have the longevity you've had, etc. You're at a level that most developers will never achieve in their career. Think about folks that are less experienced, or with fewer natural gifts, etc and sometimes you come up with different answers.
Conceptually, IHMO, packages in Fedora should be as close to upstream as possible. Toolchain selection is a piece of that. The major exception in my mind is flag selection, particularly due to the need to enforce consistent security hardening, distro-wide optimizations, or ISA selection to ensure the bits run everywhere they're supposed to.
If I understand the LO case, it is just that LO sometimes uses the Skia library which is written by Google and Google likes compiler monoculture and is using heavily #ifdef __clang__ in it and using the clang variants of the generic vectors guarded by that, and as fallback just doesn't use simd. I believe Honza Hubicka had quite some changes for Skia, not sure if they went upstream already or not. But the maintainers should be able to choose, build just Skia with clang and rest of LO with GCC, or everything with GCC and with help from us get Skia into shape for better portability (that would be ideal, but of course can mean more hopefully one time work), or build all of it with Clang/LLVM.
Again, I'd fall back to the "what does upstream do". DOing something different should require strong technical justification and none of the stuff I've seen discussed around LO, Firefox or Chromium would meet that bar IMHO.
jeff
On Fri, 2020-06-05 at 21:49 +0200, Jakub Jelinek wrote:
On Fri, Jun 05, 2020 at 01:36:37PM -0600, Jeff Law wrote:
On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: ...
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases.
But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC.
Why? Shouldn't the Fedora maintainers be able to decide this? If they have been using GCC for years and it hasn't been an obstackle for them, why should they switch?
The experts in a particular codebase are going to be the upstream maintainers, not Fedora packagers. Sometimes those are the same developers, but often they are not. In the former case, obviously the right thing will "just happen". In the latter the upstream is the right place to be making this decision.
If I understand the LO case, it is just that LO sometimes uses the Skia library which is written by Google and Google likes compiler monoculture and is using heavily #ifdef __clang__ in it and using the clang variants of the generic vectors guarded by that, and as fallback just doesn't use simd. I believe Honza Hubicka had quite some changes for Skia, not sure if they went upstream already or not.
If I read that patch correctly, they were prefering Clang/LLVM just in the skia library and not across the whole project -- which also seems like a valid case to me. If part of a project wants to use Clang/LLVM and another part is using GCC, then that's the project's decision. That decision has consequences (like the inability to LTO across those components), but again, the upstream project is going to be in the best position to make that decision.
But the maintainers should be able to choose, build just Skia with clang and rest of LO with GCC, or everything with GCC and with help from us get Skia into shape for better portability (that would be ideal, but of course can mean more hopefully one time work), or build all of it with Clang/LLVM.
I would agree if you inserted "upstream" before "maintainers" here :-)
I do think that we could/should have an exception policy where the Fedora packager could make a case to do something different from upstream WRT toolchain selection. But that should be an exceptional case, not the norm.
jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote:
On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: ...
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases.
But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC.
Also does this mean that Clang is now fully supported compiler by full- time working people @ Red Hat in toolchains team that are also contributing to upstream? Just curious if we will be able to "fully support" people when we find bugs in the compiler.
Yes. Absolutely. Tom S & Serge G directly. Others in a more indirect capacity.
And also, does it mean that we will be following same pattern as with GCC to test pre-release versions in rawhide, do the mass rebuild and so on?
Some of that is already happening internally. Tom's got a tester which spins Fedora packages with Clang/LLVM. I'm not sure if he's trying to cover the whole distro, but it is running regularly (it shares a jenkins instance with my tester).
...
I think this is not fully true because clang / gcc produce different binaries in terms of size / performance. So just switching compiler in some package may result in significat (hopefully not) performance gain / drop.
Certainly switching compilers can result in performance changes. Having been through this kind of disruptive change on the other side (GCC vs various vendor compilers through the 90s), what tends to happen is the compilers get to a point where they're typically +-5% of each other on the vast majority of codes. That's where Clang/LLVM and GCC are today based on the data I've seen.
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.
Clang/LLVM is closing that gap rapidly. I fully expect stack clash protection to be at parity on the relevant platforms except aarch64 by LLVM 11 and a reasonable chance to reach parity on aarch64 by LLVM 12.
Sure thing! I just asked to have it documented that as of F33 it is not yet implemented, but is planned to be worked on. So that users do not expect it to have all security features built-in as on F33.
...
I think this should mention that annobin plugin should be prepared for clang.
Nick Clifton is already working on that :-)
Jeff _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Fri, 2020-06-05 at 21:51 +0200, Igor Raits wrote:
On Fri, 2020-06-05 at 13:36 -0600, Jeff Law wrote:
On Thu, 2020-06-04 at 16:30 -0400, Igor Raits wrote: ...
Sadly some upstreams insist on clang just because they like it more, without any technical reason. The question that comes to my mind: Should we still try to convince upstreams to use GCC in such cases or not?
It happens (choosing Clang because they like it) and while we can (and have) engaged upstreams on this topic and I suspect we will continue to do so in some cases.
But in the end I think we still have to respect the upstream project's choices, even if it's just because they like Clang/LLVM more than GCC.
Also does this mean that Clang is now fully supported compiler by full- time working people @ Red Hat in toolchains team that are also contributing to upstream? Just curious if we will be able to "fully support" people when we find bugs in the compiler.
Yes. Absolutely. Tom S & Serge G directly. Others in a more indirect capacity.
And also, does it mean that we will be following same pattern as with GCC to test pre-release versions in rawhide, do the mass rebuild and so on?
Some of that is already happening internally. Tom's got a tester which spins Fedora packages with Clang/LLVM. I'm not sure if he's trying to cover the whole distro, but it is running regularly (it shares a jenkins instance with my tester).
...
I think this is not fully true because clang / gcc produce different binaries in terms of size / performance. So just switching compiler in some package may result in significat (hopefully not) performance gain / drop.
Certainly switching compilers can result in performance changes. Having been through this kind of disruptive change on the other side (GCC vs various vendor compilers through the 90s), what tends to happen is the compilers get to a point where they're typically +-5% of each other on the vast majority of codes. That's where Clang/LLVM and GCC are today based on the data I've seen.
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.
Clang/LLVM is closing that gap rapidly. I fully expect stack clash protection to be at parity on the relevant platforms except aarch64 by LLVM 11 and a reasonable chance to reach parity on aarch64 by LLVM 12.
Sure thing! I just asked to have it documented that as of F33 it is not yet implemented, but is planned to be worked on. So that users do not expect it to have all security features built-in as on F33.
Where do we want this documented? I don't mind adding verbage to the change proposal around this, but I fear that's really not the right place and the info will get lost. Perhaps make it part of the packaging guidelines change if/when we make a change?
jeff
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@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.
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.
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.
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 09:52 +0200, Kevin Kofler wrote:
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@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.
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.
Since I was not sure if clang is supported by Red Hat Toolchain team in the same way as GCC, I've asked this in my reply. If they are supported in the same manner (maintainers are as well developers in upstream and work full-time on this, development versions are being tested in rawhide early, etc…) I do not see a reason to disallow that.
- From the security features, do you have some specifics in mind? I saw only from our CFLAGS/LDFLAGS, only the -fstack-clash-protection is not yet supported, but it is being worked on (already in trunk, though only for x86).
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.
Well, if they are supported in the same way as GCC (in the sense as it is not just being packaged in Fedora, but developed and properly tested in Fedora), why not to declare that we have 2 system compilers? Regarding hidden binary incompatibilities, those are the bugs that needs to be fixed so I assume if maintainers of clang make commitment, they will have to fix it because Clang will be 2nd system compiler.
Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 09:52 +0200, Kevin Kofler wrote: ...
Since I was not sure if clang is supported by Red Hat Toolchain team in the same way as GCC, I've asked this in my reply. If they are supported in the same manner (maintainers are as well developers in upstream and work full-time on this, development versions are being tested in rawhide early, etc…) I do not see a reason to disallow that.
Yup. As mentioned in my previous message. Tom S in Red Hat's LLVM lead with Serge G. directly contributing to LLVM and a couple others that are more indirect contributors.
- From the security features, do you have some specifics in mind? I saw
only from our CFLAGS/LDFLAGS, only the -fstack-clash-protection is not yet supported, but it is being worked on (already in trunk, though only for x86).
As mentioned elsewhere, LLVM 10 adds x86_64, LLVM 11 should add Power and Z and LLVM 12 adding AArch64.
...
Well, if they are supported in the same way as GCC (in the sense as it is not just being packaged in Fedora, but developed and properly tested in Fedora), why not to declare that we have 2 system compilers? Regarding hidden binary incompatibilities, those are the bugs that needs to be fixed so I assume if maintainers of clang make commitment, they will have to fix it because Clang will be 2nd system compiler.
Precisely. I think between Tom & Serge with direct upstream work and my contacts into the LLVM groups at IBM and ARM I'm confident we'll be able to deal with issues.
Or to look at it another way. Red Hat's supported offerings already include full support for Clang/LLVM (using libstdc++, not libc++) and GCC. They have to work and they have to work together. Red Hat is already in a dual compiler world.
Jeff
On Fri, Jun 5, 2020 at 9:57 AM Kevin Kofler kevin.kofler@chello.at wrote:
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@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.
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.
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.
I don't think we should force Fedora Contributors (Packagers) to change/fix their packages to compile with GCC if upstream decides, supports and tests GCC. There are tons of gcc specific patches in chromium [0], there were some issues in Firefox [1]. Apart from browsers, LibreOffice is going to use LLVM/Clang from Release 7.0 too, so that would potentially be another added work to LibreOffice packagers in the future.
I believe we should make packaging as easy as possible and allowing packagers to work with compilers that have upstream support is a great way to make their lives easier.
I don't know how much of an issue is currently missing -fstack-clash-protection support LLVM, but if Mozilla distributes official Firefox binaries without that flag, Google distributes Chrome without it, I feel it's not a big deal.
[0] https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_205 # To line 250 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1601707
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 10:15 +0200, Frantisek Zatloukal wrote:
On Fri, Jun 5, 2020 at 9:57 AM Kevin Kofler kevin.kofler@chello.at wrote:
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@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.
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.
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.
I don't think we should force Fedora Contributors (Packagers) to change/fix their packages to compile with GCC if upstream decides, supports and tests GCC. There are tons of gcc specific patches in chromium [0], there were some issues in Firefox [1]. Apart from browsers, LibreOffice is going to use LLVM/Clang from Release 7.0 too, so that would potentially be another added work to LibreOffice packagers in the future.
I believe we should make packaging as easy as possible and allowing packagers to work with compilers that have upstream support is a great way to make their lives easier.
I would emphasize here that we should do that as long as performance does not degrade. Even though it is not really easy to measure it, many upstreams have some benchmarks so we possibly run those somewhere in Fedora to see performance changes over time. But I would not block the change on this.
I don't know how much of an issue is currently missing -fstack-clash-protection support LLVM, but if Mozilla distributes official Firefox binaries without that flag, Google distributes Chrome without it, I feel it's not a big deal.
Well, upstreams are not necessarily enabling many security features or optimizations. So you are effectively saying "upstream knows better" where I would have to disagree with you.
[0] https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_205 # To line 250 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1601707 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On 05/06/20 10:26 +0200, Igor Raits wrote:
Well, upstreams are not necessarily enabling many security features or optimizations. So you are effectively saying "upstream knows better" where I would have to disagree with you.
Yes, this is a very good point.
Many of Fedora's packages have upstreams that are not using the latest compilers, libraries, security features etc.
Just because upstream hasn't been updated to work with compiler hardening features doesn't mean we should disable those features. Just because upstream's code is not portable to more than one compiler doesn't mean we shouldn't send them bugs (or better still, patches).
On 05/06/20 10:26 +0200, Igor Raits wrote: ...
Well, upstreams are not necessarily enabling many security features or optimizations. So you are effectively saying "upstream knows better" where I would have to disagree with you.
Yes, this is a very good point.
Many of Fedora's packages have upstreams that are not using the latest compilers, libraries, security features etc.
Just because upstream hasn't been updated to work with compiler hardening features doesn't mean we should disable those features. Just because upstream's code is not portable to more than one compiler doesn't mean we shouldn't send them bugs (or better still, patches).<>
Right. Though I think the security side of this largely belongs in redhat-rpm- config and moving annobin/annocheck into an enforcement role (like we've done with RHEL).
We did this for RHEL and while painful, getting the vast majority of packages to honor the flags injection and verification via annobin/annocheck before the resultant packages can be included in the distro has been a big win and enables us to do a lot of useful things knowing that the flags injection works well.
Fedora is behind on this. While most packages honor flags injection, we don't actually know which do not (either by accident or design) and we don't have a way to easily find them. So things like CET in enforcing mode by default are going to be harder to achieve in Fedora than in RHEL. But like so many things, I don't have the time to push on something like this for Fedora.
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 13:53 -0600, Jeff Law wrote:
On 05/06/20 10:26 +0200, Igor Raits wrote: ...
Well, upstreams are not necessarily enabling many security features or optimizations. So you are effectively saying "upstream knows better" where I would have to disagree with you.
Yes, this is a very good point.
Many of Fedora's packages have upstreams that are not using the latest compilers, libraries, security features etc.
Just because upstream hasn't been updated to work with compiler hardening features doesn't mean we should disable those features. Just because upstream's code is not portable to more than one compiler doesn't mean we shouldn't send them bugs (or better still, patches).<>
Right. Though I think the security side of this largely belongs in redhat-rpm- config and moving annobin/annocheck into an enforcement role (like we've done with RHEL).
We did this for RHEL and while painful, getting the vast majority of packages to honor the flags injection and verification via annobin/annocheck before the resultant packages can be included in the distro has been a big win and enables us to do a lot of useful things knowing that the flags injection works well.
Fedora is behind on this. While most packages honor flags injection, we don't actually know which do not (either by accident or design) and we don't have a way to easily find them. So things like CET in enforcing mode by default are going to be harder to achieve in Fedora than in RHEL. But like so many things, I don't have the time to push on something like this for Fedora.
Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or?
Jeff _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote:
Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or?
So we have a step that sits between the build phase and when the resultant packages land in the distro which runs annocheck to validate options used, CET coverage across the binary, PIE, etc etc. If that annocheck run fails, then the packages are not allowed into the distribution, buildroots, etc.
We flipped it on a couple years ago in the run up to RHEL 8 and it proved to be quite valuable.
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 14:16 -0600, Jeff Law wrote:
On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote:
Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or?
So we have a step that sits between the build phase and when the resultant packages land in the distro which runs annocheck to validate options used, CET coverage across the binary, PIE, etc etc. If that annocheck run fails, then the packages are not allowed into the distribution, buildroots, etc.
We flipped it on a couple years ago in the run up to RHEL 8 and it proved to be quite valuable.
Seems like a thing we should do in Fedora CI for each update!
Thanks again for all the work on making distribution better!
Jeff
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Fri, 2020-06-05 at 22:22 +0200, Igor Raits wrote:
On Fri, 2020-06-05 at 14:16 -0600, Jeff Law wrote:
On Fri, 2020-06-05 at 22:07 +0200, Igor Raits wrote:
Just curious, how is it done in RHEL? Just some kind of CI that analyses all builds or?
So we have a step that sits between the build phase and when the resultant packages land in the distro which runs annocheck to validate options used, CET coverage across the binary, PIE, etc etc. If that annocheck run fails, then the packages are not allowed into the distribution, buildroots, etc.
We flipped it on a couple years ago in the run up to RHEL 8 and it proved to be quite valuable.
Seems like a thing we should do in Fedora CI for each update!
Possibly. It requires some work on by the packagers to understand the new requirements and how to interpret the annocheck results. Nick & Florian spent countless hours working with RHEL developers to understand and fix packaging issues. But it's awful nice once it's in and everyone's updated their packages.
jeff
On 05/06/2020 10:15, Frantisek Zatloukal wrote:
[...] Apart from browsers, LibreOffice is going to use LLVM/Clang from Release 7.0 too, so that would potentially be another added work to LibreOffice packagers in the future.
Just to clarify, upstream LibreOffice supports both GCC and Clang on Linux equally well since ~forever, and there is no change coming for LO 7.0 that I'm aware of. Upstream Linux binaries are built with GCC, FWIW.
On Fri, Jun 5, 2020 at 1:51 PM Stephan Bergmann sbergman@redhat.com wrote:
On 05/06/2020 10:15, Frantisek Zatloukal wrote:
[...] Apart from browsers, LibreOffice is going to use LLVM/Clang from Release 7.0 too, so that would potentially be another added work to LibreOffice packagers in the future.
Just to clarify, upstream LibreOffice supports both GCC and Clang on Linux equally well since ~forever, and there is no change coming for LO 7.0 that I'm aware of. Upstream Linux binaries are built with GCC, FWIW.
I think what they are referring to is that there was a patch [1] a few months ago making Clang *preferred* for building the LibreOffice rendering code in response to a slow-performance bug [2].
[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=647499ef8151d938398... [2] https://bugs.documentfoundation.org/show_bug.cgi?id=131697
On 05/06/2020 15:16, Ian McInerney wrote:
On Fri, Jun 5, 2020 at 1:51 PM Stephan Bergmann <sbergman@redhat.com mailto:sbergman@redhat.com> wrote:
On 05/06/2020 10:15, Frantisek Zatloukal wrote: > [...] Apart from > browsers, LibreOffice is going to use LLVM/Clang from Release 7.0 too, > so that would potentially be another added work to LibreOffice packagers > in the future. Just to clarify, upstream LibreOffice supports both GCC and Clang on Linux equally well since ~forever, and there is no change coming for LO 7.0 that I'm aware of. Upstream Linux binaries are built with GCC, FWIW.
I think what they are referring to is that there was a patch [1] a few months ago making Clang /preferred/ for building the LibreOffice rendering code in response to a slow-performance bug [2].
[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=647499ef8151d938398... [2] https://bugs.documentfoundation.org/show_bug.cgi?id=131697
Yes, exclusively for LO's copy of the skia library (and which isn't of much use for LO on Fedora anyway, at least for now).
Frantisek Zatloukal wrote:
I don't think we should force Fedora Contributors (Packagers) to change/fix their packages to compile with GCC if upstream decides, supports and tests GCC.
While that sentence parses, it fails the semantic analysis in my brain. ;-) I think that either the second "GCC" is wrong here or you are missing a negation somewhere.
There are tons of gcc specific patches in chromium [0]
Hmmm, looks like the situation has worsened recently, several of those patches are now downstream (or sidestream, e.g., copied from Gentoo). Chromium used to actually commit compile fixes for newer GCC releases in its master branch, just as projects using GCC primarily do as well, and the GCC-related patches in the Fedora specfile were mostly backported from there. What I see now makes me less happy.
That said, the Chromium package no longer carrying such patches is going to make it harder for QtWebEngine to keep up with new GCC releases (and their incompatible changes). QtWebEngine defaults to building everything including the bundled Chromium fork with the toolchain Qt was built with. This is obviously GCC, and not likely to change any time soon (unless the distrowide default changes). When there is a build issue with a new GCC, chromium.spec is the first place to look for a fix. If Chromium switches to being built with Clang, the QtWebEngine maintainers will have to do all the work of tracking down the build fixes for the latest GCC on their own.
Now, Qt upstream actually systematically tests building QtWebEngine with GCC, so we do not have to apply so many GCC build fixes there. (They are often already applied by Qt upstream.) The problem is just that Rawhide typically has a newer GCC than the rest of the world.
But all that said, if the situation is really that Chromium requires so many downstream patches to even compile with GCC, then it actually falls under the already preexisting "upstream does not support GCC and/or the code does not compile with GCC" exception and this change is actually not needed at all for Chromium. The change only affects projects where upstream actually supports both compilers, but prefers Clang for whatever reason. And there, I do not think we should be bound by upstream's preference.
Kevin Kofler
On Fri, Jun 5, 2020 at 9:56 AM Kevin Kofler kevin.kofler@chello.at 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.
Kevin, that's not true at all. Maybe it looks like it builds fine for you, because all the fixes get to you, but I as a co-maintainer of Chromium in Fedora and ex-maintainer of Chromium in RHEL can say that most of the time I spent fixing GCC problems. Just look at the current SPEC file and search for gcc there.. There are several gcc related bugs - https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec. Or even better look at https://bugs.chromium.org/p/chromium/issues/detail?id=819294 where the GCC related patches are tracked. In the end I realized that I really don't have time to fix all the time some GCC related issues so I moved the RHEL 6 Chromium package to use clang to save some of my time so I could devote it somewhere else.
Bye, Tom
On 05/06/20 10:23 +0200, Tomáš Popela wrote:
On Fri, Jun 5, 2020 at 9:56 AM Kevin Kofler kevin.kofler@chello.at 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.
Kevin, that's not true at all. Maybe it looks like it builds fine for you, because all the fixes get to you, but I as a co-maintainer of Chromium in Fedora and ex-maintainer of Chromium in RHEL can say that most of the time I spent fixing GCC problems. Just look at the current SPEC file and search for gcc there.. There are several gcc related bugs - https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec. Or even better look at https://bugs.chromium.org/p/chromium/issues/detail?id=819294 where the GCC
The very first one there is just a bug in Chromium: using a type without including the header that defines it. There are several others like that (relying on unique_ptr bing declared implicitly, relying on nullptr_t being declared implicitly ...)
Those are upstream bugs and should be fixed. Period.
Otherwise chromium will become a ghetto^W monoculture that can't be built with anything except one compiler. And maybe one day a change in libc++ would have broken chromium anyway.
"libstdc++: do not assume unique_ptr has ostream operator"
It would be nice if somebody had reported this to libstdc++ as a bug, so it could be fixed. That was found in chromium over a year ago. Sigh. I'll fix that on Monday (I have the day off today) but if it had been reported last year it could have been fixed in GCC 9 and 10 by now.
"Explicit specialization in non-namespace scope is not allowed in C++, and GCC breaks build because of that."
"The notation for initialization of structs referring to its properties is invalid in C++. This is not accepted in GCC."
So chromium is using non-standard C++.
Part of the problem seems to be that upstream are not good citizens in the open source community. Improving the portability of the code (and also finding GCC bugs and so improving GCC) is a Good Thing™.
related patches are tracked. In the end I realized that I really don't have time to fix all the time some GCC related issues so I moved the RHEL 6 Chromium package to use clang to save some of my time so I could devote it somewhere else.
That's fair. But those issues *should* get fixed, by someone. If they don't, we all lose out. But I totally get that you need to be able to build it and ship it, and using Clang allows that. I just fear that if nobody finds the issues, the whole ecosystem suffers.
tl;dr This is a chromium problem, not just a GCC problem. Fixing those portability problems is an investment and reduces technical debt.
On Fri, 2020-06-05 at 09:59 +0100, Jonathan Wakely wrote:
On 05/06/20 10:23 +0200, Tomáš Popela wrote:
On Fri, Jun 5, 2020 at 9:56 AM Kevin Kofler <kevin.kofler(a)chello.at> 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.
Kevin, that's not true at all. Maybe it looks like it builds fine for you, because all the fixes get to you, but I as a co-maintainer of Chromium in Fedora and ex-maintainer of Chromium in RHEL can say that most of the time I spent fixing GCC problems. Just look at the current SPEC file and search for gcc there.. There are several gcc related bugs - https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec. Or even better look at https://bugs.chromium.org/p/chromium/issues/detail?id=819294 where the GCC
The very first one there is just a bug in Chromium: using a type without including the header that defines it. There are several others like that (relying on unique_ptr bing declared implicitly, relying on nullptr_t being declared implicitly ...)
Those are upstream bugs and should be fixed. Period.
Yup. And what you're hitting on is a real issue. Monocultures are generally bad. All the world is a vax, all the world is a sparc (running solaris), all the world is x86-linux, everything builds with gcc and so-on.
There's a secondary problem you're touching on and that's engagement to get stuff fixed correctly. Finding the balance there can be hard too, particularly if the developer doesn't know *how* to engage a particular community. I run into this myself and it can be frustrating. So while I'd rather see better engagement on bugs, I do understand why a Chromium developer might not have reported issues to the GCC community.
In an ideal world, everything would build with both compilers, folks would review and fix all the diagnostics they generate. Selection of which binaries would essentially happen at the end of the build cycle with the decision made on a per- package basis. However, I strongly suspect the pitchforks would be out if we tried to go that far :-)
[ ... ]
tl;dr This is a chromium problem, not just a GCC problem. Fixing those portability problems is an investment and reduces technical debt.
It's a balance and judgment call. For Chromium and Firefox the cost of maintaining GCC as a build toolchain has apparently outgrown the cost of non- portable code. Of course the cost of the latter usually does show up until much later in a product's lifecycle, so only time will tell if those projects have made a good decision.
Jeff
On Fri, Jun 05, 2020 at 09:52:09AM +0200, Kevin Kofler wrote:
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.
I'll note that there are some even not really hidden binary incompatibilities, where LLVM diverges from the psABI for years, it has been reported and nothing has been changed. So if a library is built with clang/LLVM and used by GCC built package or vice versa, one might very well run into those (this is e.g. about passing std::byte or other scoped enums with char/short underlying type by value, or in some cases even about passing char/short arguments). And of course unknown ABI bugs on both sides.
Jakub
On Fri, 2020-06-05 at 11:19 +0200, Jakub Jelinek wrote:
On Fri, Jun 05, 2020 at 09:52:09AM +0200, Kevin Kofler wrote:
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.
I'll note that there are some even not really hidden binary incompatibilities, where LLVM diverges from the psABI for years, it has been reported and nothing has been changed. So if a library is built with clang/LLVM and used by GCC built package or vice versa, one might very well run into those (this is e.g. about passing std::byte or other scoped enums with char/short underlying type by value, or in some cases even about passing char/short arguments). And of course unknown ABI bugs on both sides.
So the new policy is only for non-library packages then? Packages which provide libraries that can be linked to by other packages still need to use the default system compiler to make sure there is no breakage. At least to the other packages. A package that is build with llvm might subtly break when linked against system libraries.
Thanks,
Mark
On Fri, 2020-06-05 at 15:04 +0200, Mark Wielaard wrote:
On Fri, 2020-06-05 at 11:19 +0200, Jakub Jelinek wrote:
On Fri, Jun 05, 2020 at 09:52:09AM +0200, Kevin Kofler wrote:
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.
I'll note that there are some even not really hidden binary incompatibilities, where LLVM diverges from the psABI for years, it has been reported and nothing has been changed. So if a library is built with clang/LLVM and used by GCC built package or vice versa, one might very well run into those (this is e.g. about passing std::byte or other scoped enums with char/short underlying type by value, or in some cases even about passing char/short arguments). And of course unknown ABI bugs on both sides.
So the new policy is only for non-library packages then? Packages which provide libraries that can be linked to by other packages still need to use the default system compiler to make sure there is no breakage. At least to the other packages. A package that is build with llvm might subtly break when linked against system libraries.
No, it makes no distinction between library and other packages.
Clang/LLVM and GCC are ABI compatible (with the known exception of the alignment issue for atomics) and one should be able to mix and match libraries compiled by one with code compiled by the other just fine.
Perhaps you're worried about libc++ (the Clang/LLVM C++ runtime)? We don't use or support libc++ in Fedora because it is not ABI compatible with libstdc++ and an object created by one library can not be used/manipulated by the other (or instantiated templates from the other).
If you're aware of ABI compatibility issues between the compilers, certainly chime in here, the appropriate BZ or to me directly. You can even raise it in the Tuesday meetings with the LLVM/GCC teams -- I'm sure that if there's an issue that both Tom and I will want to know about it.
jeff
On Fri, Jun 05, 2020 at 03:03:18PM -0600, Jeff Law wrote:
Clang/LLVM and GCC are ABI compatible (with the known exception of the alignment issue for atomics) and one should be able to mix and match libraries compiled by one with code compiled by the other just fine.
They are known not to be ABI compatible, see e.g. https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207 That is just one arch, has anyone e.g. tried gcc make check-gcc check-c++-all RUN_ALL_COMPAT_TESTS=1 ALT_CC_UNDER_TEST=clang \ ALT_CXX_UNDER_TEST=clang++ RUNTESTFLAGS=struct-layout-1.exp on different architectures? That might come up with more.
Is e.g. C++ struct A {}; struct B { [[no_unique_address]] A a; double b; }; passed by value the same between g++ 10 and latest clang++?
Jakub
On Fri, 2020-06-05 at 23:16 +0200, Jakub Jelinek wrote:
On Fri, Jun 05, 2020 at 03:03:18PM -0600, Jeff Law wrote:
Clang/LLVM and GCC are ABI compatible (with the known exception of the alignment issue for atomics) and one should be able to mix and match libraries compiled by one with code compiled by the other just fine.
They are known not to be ABI compatible, see e.g. https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207 That is just one arch, has anyone e.g. tried gcc make check-gcc check-c++-all RUN_ALL_COMPAT_TESTS=1 ALT_CC_UNDER_TEST=clang \ ALT_CXX_UNDER_TEST=clang++ RUNTESTFLAGS=struct-layout-1.exp on different architectures? That might come up with more.
Is e.g. C++ struct A {}; struct B { [[no_unique_address]] A a; double b; }; passed by value the same between g++ 10 and latest clang++?
It's a bug and should be treated as such. Given it's a c++20 feature I wouldn't consider it terribly concerning at this stage. Hell, gcc's been all over the map with this stuff varying release-to-release, particularly for the empty baseclass stuff.
Jeff
On Mon, Jun 08, 2020 at 10:02:53AM -0600, Jeff Law wrote:
On Fri, 2020-06-05 at 23:16 +0200, Jakub Jelinek wrote:
On Fri, Jun 05, 2020 at 03:03:18PM -0600, Jeff Law wrote:
Clang/LLVM and GCC are ABI compatible (with the known exception of the alignment issue for atomics) and one should be able to mix and match libraries compiled by one with code compiled by the other just fine.
They are known not to be ABI compatible, see e.g. https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C19909%2C44228%2C12207 That is just one arch, has anyone e.g. tried gcc make check-gcc check-c++-all RUN_ALL_COMPAT_TESTS=1 ALT_CC_UNDER_TEST=clang \ ALT_CXX_UNDER_TEST=clang++ RUNTESTFLAGS=struct-layout-1.exp on different architectures? That might come up with more.
Is e.g. C++ struct A {}; struct B { [[no_unique_address]] A a; double b; }; passed by value the same between g++ 10 and latest clang++?
It's a bug and should be treated as such. Given it's a c++20 feature I wouldn't consider it terribly concerning at this stage. Hell, gcc's been all over the map with this stuff varying release-to-release, particularly for the empty baseclass stuff.
The query above are bugs not related to c++20, and in some of them from the comments it appears LLVM is not willing to fix but instead want to try to change the psABI. The psABI authors stated that they don't intend to change it though.
Jakub
On Mon, Jun 08, 2020 at 06:19:40PM +0200, Jakub Jelinek wrote:
The query above are bugs not related to c++20, and in some of them from the comments it appears LLVM is not willing to fix but instead want to try to change the psABI. The psABI authors stated that they don't intend to change it though.
And I'll add that the 8/16-bit passing bug isn't something theoretic, but it affects a lot of real-world code.
Jakub
Dne 05. 06. 20 v 9:52 Kevin Kofler napsal(a):
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@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.
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.
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.
Just FTR, there are technical (and security) reasons why we might consider switching Ruby from GCC to Clang in the future:
https://bugzilla.redhat.com/show_bug.cgi?id=1721553
Vít
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Friday, June 5, 2020 5:42:36 AM EDT Vít Ondruch wrote:
Dne 05. 06. 20 v 9:52 Kevin Kofler napsal(a):
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@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.
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.
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.
Just FTR, there are technical (and security) reasons why we might consider switching Ruby from GCC to Clang in the future:
I don't think allowing builds with Clang are necessarily bad. It has one interesting feature that actually helps security.
-ftrivial-auto-var-init=zero
what this does is initialize to zero any variable that it detects is uninitialized. This can prevent leaking secrets in network protols if memset was forgotten and it prevents attacks where the value of the stack or heap is groomed to a certain value to enable an exploit. In one conference presentation, it was said that 900 fixed CVE's in Chrome and 12% of all Android CVE's would have been prevented with this feature.
I am wondering if that should be a default flag for clang builds?
And if you do fuzzing, you can compile AFL with clang and its more powerful.
There's pro's and cons.
-Steve
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.
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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.
I would rather see us still *strongly prefer* GCC rather than allowing this to be freely changeable at a whim.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Fri, Jun 5, 2020 at 8:26 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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.
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@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
?
Rich.
On Fri, Jun 5, 2020 at 10:24 AM Richard W.M. Jones rjones@redhat.com wrote:
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@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
?
Yes. We cannot reasonably implement this and that feature.
On 06/05/2020 08:05 AM, Neal Gompa wrote:
On Fri, Jun 5, 2020 at 10:24 AM Richard W.M. Jones rjones@redhat.com wrote:
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@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
?
Yes. We cannot reasonably implement this and that feature.
The only way this would be an issue is if you had one package that was built using both gcc and clang. In that case, you could not use LTO. Otherwise, it doesn't matter that the LTO formats are not compatible, because the proposal explicitly says we will not be shipping LTO bytecode.
-Tom
On 6/5/20 5:27 AM, Neal Gompa wrote:
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.
As others mentioned, LTO will be contained to a specific package build.
Allowing Clang can also *improve* LTO. Specifically, Firefox has a mix of C++ (could use GCC or Clang) and Rust (always LLVM). With Clang, they'd have an all-LLVM build, and could enable cross-language LTO:
http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html
On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
Stop this. This change is driven by the Red Hat toolchain team directly, at their own realization that Fedora's compiler policy is out of line with upstream reality today. They suggested it, they submitted it, and they are driving it. Chromium is used as an example only. Please stop gaslighting why Changes are being submitted in Fedora.
Focus on the technical merits all you want.
josh
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.
I would rather see us still *strongly prefer* GCC rather than allowing this to be freely changeable at a whim.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
Stop this. This change is driven by the Red Hat toolchain team directly, at their own realization that Fedora's compiler policy is out of line with upstream reality today. They suggested it, they submitted it, and they are driving it. Chromium is used as an example only. Please stop gaslighting why Changes are being submitted in Fedora.
Focus on the technical merits all you want.
Hi Josh, I think (not sure, but I do) that you misread Neal message as accusing the Fedora packagers of Chromium, while I think Neal was blaming Chromium upstream for not caring about anything bug clang and making life hard downstream.
I do not know what is what at this point, but please let's all try to read positive intent first and explain each other.
sincerely, Simo.
josh
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.
I would rather see us still *strongly prefer* GCC rather than allowing this to be freely changeable at a whim.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Fri, Jun 5, 2020 at 3:50 PM Simo Sorce simo@redhat.com wrote:
On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
Stop this. This change is driven by the Red Hat toolchain team directly, at their own realization that Fedora's compiler policy is out of line with upstream reality today. They suggested it, they submitted it, and they are driving it. Chromium is used as an example only. Please stop gaslighting why Changes are being submitted in Fedora.
Focus on the technical merits all you want.
Hi Josh, I think (not sure, but I do) that you misread Neal message as accusing the Fedora packagers of Chromium, while I think Neal was blaming Chromium upstream for not caring about anything bug clang and making life hard downstream.
Precisely this. I was not accusing Fedorans of anything. And I still think that the main motivation for the RH Tools team to propose this is because of those specific upstreams. This stuff doesn't come out of a vacuum after all.
I do not know what is what at this point, but please let's all try to read positive intent first and explain each other.
I was particularly confused and hurt by the accusation, especially since I almost never interact with Josh even when I want to. :(
-- 真実はいつも一つ!/ Always, there's only one truth!
On Fri, Jun 5, 2020, 4:15 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 5, 2020 at 3:50 PM Simo Sorce simo@redhat.com wrote:
On Fri, 2020-06-05 at 11:50 -0400, Josh Boyer wrote:
On Fri, Jun 5, 2020 at 8:27 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel devel@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
Stop this. This change is driven by the Red Hat toolchain team directly, at their own realization that Fedora's compiler policy is out of line with upstream reality today. They suggested it, they submitted it, and they are driving it. Chromium is used as an example only. Please stop gaslighting why Changes are being submitted in Fedora.
Focus on the technical merits all you want.
Hi Josh, I think (not sure, but I do) that you misread Neal message as accusing the Fedora packagers of Chromium, while I think Neal was blaming Chromium upstream for not caring about anything bug clang and making life hard downstream.
Precisely this. I was not accusing Fedorans of anything. And I still think that the main motivation for the RH Tools team to propose this is because of those specific upstreams. This stuff doesn't come out of a vacuum after all.
I do not know what is what at this point, but please let's all try to read positive intent first and explain each other.
I was particularly confused and hurt by the accusation, especially since I almost never interact with Josh even when I want to. :(
Sincere apologies Neal. I misread, overreacted, and took out Fedora frustrations on you. I have no excuse.
I'm taking a break from Fedora for a while.
josh
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 05/06/20 12:46 +0200, Vitaly Zaitsev via devel 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.
Yes, GCC doesn't support any architectures, or have any optimizations.
It doesn't have any features either: https://en.cppreference.com/w/cpp/compiler_support
GCC is a legacy compiler. It should be completely replaced by Clang in the nearest future.
You know what they say about opinions.
On 04/06/20 16:30 -0400, Ben Cotton wrote:
[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.
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?).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
On 04/06/20 16:30 -0400, Ben Cotton wrote:
[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.
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.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
On 04/06/20 16:30 -0400, Ben Cotton wrote:
[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/
Fixed.
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 :)
Agreed 100%. Based on comments from others I've already updated the proposal to hopefully clarify this change is strictly the compiler and does not include the runtime.
Trying to support libc++ would be a compatibility nightmare. I do believe one day we'll need to do something there, but now isn't the time to open that discussion.
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.
If they're on equal footing upstream, then no I don't think changing would be the right thing to do. I don't think that's really the case for Firefox or Chromium. I'm less familiar with the LibreOffice situation, so I won't try to give an opinion there.
Perhaps in this case we leave it up to the Fedora packager?
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.
So that text was literally copy and pasted from internal discussions. So, yea, it's my opinion and I think it's one of the option questions this body needs to hammer out to more precisely define any updated policy.
My preference would be to stick with GCC when upstream has no recommendations/support policy around supported compilers to avoid unnecessary churn.
I would also be willing to support the Fedora packager's discretion if they can make a case for it and upstream has no strong preference. For example a packager may simply be more familiar with Clang/LLVM and thus more adept at understanding what a particular diagnostic means and how to fix it properly.
Changing, but then expecting you, Tom, Jason or someone else to fix or interpret diagnostics for them no longer working code isn't reasonable IMHO.
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.
I could live with this so long as we define "good reason" to include upstream preferring one toolchain over the other.
"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.
I think we're actually largely in agreement. I don't want change for change's sake or because the cool developers use X Y or Z. I want the change to have a real technical reason behind it.
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?).
You may remember me advocating for this in our meeting in Montreal :-) So, yea, I'd be totally on board with something like this. I think Tillman was also interested and even floated the idea of finding additional Fedora builder resources to facilitate this kind of scheme.
The big problem then becomes getting packagers to address the diagnostics. I've been disappointed at how many packages are ignoring diagnostics (particularly those with security implications) and I'm actively looking at schemes to improve this situation :-)
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 23:11 -0600, Jeff Law wrote:
On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
On 04/06/20 16:30 -0400, Ben Cotton wrote:
[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/
Fixed.
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 :)
Agreed 100%. Based on comments from others I've already updated the proposal to hopefully clarify this change is strictly the compiler and does not include the runtime.
Trying to support libc++ would be a compatibility nightmare. I do believe one day we'll need to do something there, but now isn't the time to open that discussion.
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.
If they're on equal footing upstream, then no I don't think changing would be the right thing to do. I don't think that's really the case for Firefox or Chromium. I'm less familiar with the LibreOffice situation, so I won't try to give an opinion there.
Perhaps in this case we leave it up to the Fedora packager?
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.
So that text was literally copy and pasted from internal discussions. So, yea, it's my opinion and I think it's one of the option questions this body needs to hammer out to more precisely define any updated policy.
My preference would be to stick with GCC when upstream has no recommendations/support policy around supported compilers to avoid unnecessary churn.
I would also be willing to support the Fedora packager's discretion if they can make a case for it and upstream has no strong preference. For example a packager may simply be more familiar with Clang/LLVM and thus more adept at understanding what a particular diagnostic means and how to fix it properly.
Changing, but then expecting you, Tom, Jason or someone else to fix or interpret diagnostics for them no longer working code isn't reasonable IMHO.
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.
I could live with this so long as we define "good reason" to include upstream preferring one toolchain over the other.
"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.
I think we're actually largely in agreement. I don't want change for change's sake or because the cool developers use X Y or Z. I want the change to have a real technical reason behind it.
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?).
You may remember me advocating for this in our meeting in Montreal :- ) So, yea, I'd be totally on board with something like this. I think Tillman was also interested and even floated the idea of finding additional Fedora builder resources to facilitate this kind of scheme.
The big problem then becomes getting packagers to address the diagnostics. I've been disappointed at how many packages are ignoring diagnostics (particularly those with security implications) and I'm actively looking at schemes to improve this situation :-)
Just make them error by default and people will have to deal with it :)
Jeff _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Sat, 2020-06-06 at 07:58 +0200, Igor Raits wrote:
The big problem then becomes getting packagers to address the
diagnostics. I've been disappointed at how many packages are ignoring diagnostics (particularly those with security implications) and I'm actively looking at schemes to improve this situation :-)
Just make them error by default and people will have to deal with it :)
Easier said than done. Though having something like the annobin/annocheck stuff in place does help -- folks can't simply disable the warning in their package which I've seen happen far too often.
One of the big problems is you can end up with a ton of local patches if the upstream project doesn't take this stuff seriously. And every one of those local patches has a cost. Naturally folks object to the initial work and ongoing cost, particularly if upstream isn't on board.
So, if we do go forward with some of the ideas, they'll probably be some kind of opt-in with packages where Red Hat's tools team has significant influence taking the lead since the projects we work with regularly do generally take this stuff seriously. I have some thoughts on how to expand the set of packages covered, but I'm not particularly ready to publicize those yet :-)
jeff
Igor Raits ignatenkobrain@fedoraproject.org writes:
On Fri, 2020-06-05 at 23:11 -0600, Jeff Law 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
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.
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?).
You may remember me advocating for this in our meeting in Montreal :- ) So, yea, I'd be totally on board with something like this. I think Tillman was also interested and even floated the idea of finding additional Fedora builder resources to facilitate this kind of scheme.
The big problem then becomes getting packagers to address the diagnostics. I've been disappointed at how many packages are ignoring diagnostics (particularly those with security implications) and I'm actively looking at schemes to improve this situation :-)
Just make them error by default and people will have to deal with it :)
(I know you weren't seriously proposing that we do this, but it's an idea I've seen seriously proposed elsewhere and have experienced.)
Please do not do this for non-security diagnostics. Supporting this across a matrix of different compiler versions (and compilers) is truly awful - especially managing semantics changes between versions, and pragma stew, and behavior of compilers when asked to ignore flags they don't understand...
Thanks, --Robbie
On Mon, 2020-06-08 at 12:21 -0400, Robbie Harwood wrote:
Igor Raits ignatenkobrain@fedoraproject.org writes:
On Fri, 2020-06-05 at 23:11 -0600, Jeff Law 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
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.
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?).
You may remember me advocating for this in our meeting in Montreal :- ) So, yea, I'd be totally on board with something like this. I think Tillman was also interested and even floated the idea of finding additional Fedora builder resources to facilitate this kind of scheme.
The big problem then becomes getting packagers to address the diagnostics. I've been disappointed at how many packages are ignoring diagnostics (particularly those with security implications) and I'm actively looking at schemes to improve this situation :-)
Just make them error by default and people will have to deal with it :)
(I know you weren't seriously proposing that we do this, but it's an idea I've seen seriously proposed elsewhere and have experienced.)
Please do not do this for non-security diagnostics. Supporting this across a matrix of different compiler versions (and compilers) is truly awful - especially managing semantics changes between versions, and pragma stew, and behavior of compilers when asked to ignore flags they don't understand...
My desire is to only target security related diagnostics and quite possibly only a small subset initially. I don't see even trying to move on this until after F33 is done.
jeff
On 05/06/20 23:11 -0600, Jeff Law wrote:
On Fri, 2020-06-05 at 10:14 +0100, Jonathan Wakely wrote:
"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.
I think we're actually largely in agreement.
Yep, I think so. My concern is just with the wording of the proposal, not the intent.
I don't want change for change's sake or because the cool developers use X Y or Z. I want the change to have a real technical reason behind it.
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.
On 06/05/2020 03:42 AM, Vitaly Zaitsev via devel wrote:
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.
redhat-rpm-config-160-1.fc33 has a %toolchain_clang macro that you can put in your spec file that will only add clang supported CC flags.
-Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 08:07 -0700, Tom Stellard wrote:
On 06/05/2020 03:42 AM, Vitaly Zaitsev via devel wrote:
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.
redhat-rpm-config-160-1.fc33 has a %toolchain_clang macro that you can put in your spec file that will only add clang supported CC flags.
It is slightly different, you need to use `%global toolchain clang`, but otherwise yes.
-Tom _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Fri, Jun 5, 2020 at 10:33 AM Igor Raits ignatenkobrain@fedoraproject.org wrote:
It is slightly different, you need to use `%global toolchain clang`, but otherwise yes.
Is this documented somewhere? I've been manually sed'ing out the incompatible flags for PySide2 since it uses some clang only features.
Thanks, Richard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, 2020-06-05 at 12:36 -0500, Richard Shaw wrote:
On Fri, Jun 5, 2020 at 10:33 AM Igor Raits < ignatenkobrain@fedoraproject.org> wrote:
It is slightly different, you need to use `%global toolchain clang`, but otherwise yes.
Is this documented somewhere? I've been manually sed'ing out the incompatible flags for PySide2 since it uses some clang only features.
Not yet. Since the change is not approved, it is not something what you should be «officially» using.
Thanks, Richard _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
* Ben Cotton:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== 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.
Jeff, would you please clarify in the proposal that libc++ is out of scope (as already discussed)?
What about compiler-rt? And lld? Any other LLVM subprojects that could be relevant?
Thanks, Florian
On Fri, 2020-06-05 at 19:31 +0200, Florian Weimer wrote:
- Ben Cotton:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== 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.
Jeff, would you please clarify in the proposal that libc++ is out of scope (as already discussed)?
Yes. I haven't replied to that part of the thread yet. But yes, libc++ is out of scope. It'd be a compatibility nightmare.
What about compiler-rt? And lld? Any other LLVM subprojects that could be relevant?
I consider those out of scope as well :-) I think there's some desire to add lld into the alternatives mechanism (along side ld.bfd and ld.gold). But that's about it to the best of my knowledge.
jeff
On Fri, 2020-06-05 at 19:31 +0200, Florian Weimer wrote:
- Ben Cotton:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== 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.
Jeff, would you please clarify in the proposal that libc++ is out of scope (as already discussed)?
What about compiler-rt? And lld? Any other LLVM subprojects that could be relevant?
Done. I've modified the the change request to note that it's just compiler selection and does not apply to runtimes, linkers, debuggers, etc :-)
Jeff
On Thu, 4 Jun 2020 16:30:09 -0400 Ben Cotton bcotton@redhat.com wrote:
An obvious example is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time.
I compile firefox nightly locally from an hg repository. What I notice is that although mozilla officially states that it is possible to limit resource use, even though I set a maximum thread count, or maximum load, the clang compiler grabs every core and maxes it out to 100%. Will this change help with that? i.e. is this a clang problem? Or is my experience because of a problem with the firefox compilation process? Thanks.
On Sun, 2020-06-07 at 13:07 -0700, stan via devel wrote:
On Thu, 4 Jun 2020 16:30:09 -0400 Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy An obvious example is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time.
I compile firefox nightly locally from an hg repository. What I notice is that although mozilla officially states that it is possible to limit resource use, even though I set a maximum thread count, or maximum load, the clang compiler grabs every core and maxes it out to 100%. Will this change help with that? i.e. is this a clang problem? Or is my experience because of a problem with the firefox compilation process?
It's unclear if it's a problem in Clang/LLVM or the firefox build procedures. Regardless, this proposal shouldn't change/improve your issue in any way.
jeff
On Mon, 08 Jun 2020 09:29:27 -0600 Jeff Law law@redhat.com wrote:
On Sun, 2020-06-07 at 13:07 -0700, stan via devel wrote:
On Thu, 4 Jun 2020 16:30:09 -0400 Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy An obvious example is Firefox. Upstream, the Firefox project builds primarily with Clang/LLVM. Yet we force the Fedora package owner to find and fix issues building with GCC then either carry those custom fixes forward in Fedora or negotiate with upstream to get those changes upstreamed. While this process can be helpful in finding non-portable code, this is ultimately a poor use of the packager's time.
I compile firefox nightly locally from an hg repository. What I notice is that although mozilla officially states that it is possible to limit resource use, even though I set a maximum thread count, or maximum load, the clang compiler grabs every core and maxes it out to 100%. Will this change help with that? i.e. is this a clang problem? Or is my experience because of a problem with the firefox compilation process?
It's unclear if it's a problem in Clang/LLVM or the firefox build procedures. Regardless, this proposal shouldn't change/improve your issue in any way.
Thanks.