On 1/5/24 5:18 AM, Stephen Gallagher wrote: > On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney <amoloney@xxxxxxxxxx> wrote: >> >> Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18 >> >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal will only be implemented if approved >> by the Fedora Engineering Steering Committee. >> >> == Summary == >> Update all llvm sub-projects in Fedora Linux to version 18. >> >> >> == Owner == >> * Name: [[User:tstellar| Tom Stellard]] >> * Email: <tstellar@xxxxxxxxxx> >> >> >> == Detailed Description == >> All llvm sub-projects in Fedora will be updated to version 18, and >> there will be a soname version change for the llvm libraries. >> Compatibility packages clang17, llvm17, and lld17 will be added to >> ensure that packages that currently depend on clang and llvm version >> 17 libraries will continue to work. We may add other compatibility >> packages too if they're determined to be necessary to maintain >> functionality in other RPMS that use llvm/clang. We also plan to >> retire these older compatibility packages (that we own): >> >> * llvm14 >> * llvm15 >> * llvm16 >> * clang14 >> * clang15 >> * clang16 >> * lld14 >> * lld15 >> * lld16 >> >> We will also be asking the maintainers of the following packages to >> retire them if possible: >> >> * llvm7.0 >> * llvm8.0 >> * llvm11 >> * llvm12 >> * llvm13 >> >> Other notable changes: >> >> * clang will emit DWARF-5 by default instead of DWARF-4. This matches >> the upstream default. We have been using DWARF-4 as the default for >> the last few releases due to: >> https://bugzilla.redhat.com/show_bug.cgi?id=2064052 >> * The compatibility packages will now include the same content as the >> main package. In previous releases, the compatibility packages >> contained only libraries and headers, and the binaries and other >> content was stripped out. These packages will be supported for use as >> dependencies for other RPM packages, but not for general purpose usage >> by end users. Fedora users should use Clang/LLVM 18. >> * The compatibility packages added for Fedora 40 will be retired prior >> to the Fedora 41 branch. >> * We will be enabling Fat LTO in redhat-rpm-config if this feature is >> complete in time for the upstream LLVM 18 release. Fat LTO is a >> feature that allows the compiler to produce libraries that contain LTO >> bitcode along side the traditional ELF binary code so that the >> libraries can be linked in both LTO mode and non-LTO mode. gcc also >> supports this feature and has it enabled in Fedora. In Fedora 39 and >> older, with LTO enabled, clang produces binaries with only LTO >> bitcode, so we need to run a post-processing script >> (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code >> so they can be used by other packages. Enabling Fat LTO will allow us >> to remove this script and simplify the build process. >> >> ===LLVM Build Schedule=== >> >> ====Important Dates==== >> >> * Jan 26: Upstream: 18.0.0-rc1 Release >> * Feb 6: Fedora: f40 branch created >> * Feb 6: Upstream: 18.0.0-rc2 Release >> * Feb 20: Fedora: f40 Beta Freeze >> * Feb 20: Upstream: 18.0.0-rc3 Release >> * Mar 5: Upstream: 18.0.0 Release >> * Apr 2: Fedora: f40 Final Freeze >> >> ====Plan==== >> # Build nightly trunk (LLVM 18) snapshots in >> [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/packages/ >> copr]. >> # Build LLVM 18.0.0-rc1 in COPR. >> # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji. >> # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji. >> # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji. >> # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji. >> # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji >> # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji >> # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not >> ready) as a Beta Freeze exception. >> # Continue building new release candidates and pushing them to stable >> until the Final Freeze. >> >> We are not planning to push 18.0.0-rc1 into rawhide because the >> library ABI is not stabilized at that point. Typically, the ABI >> stabilizes after -rc3, but there are no guarantees from upstream about >> this. Given the history of minimal ABI changes after -rc3, we feel >> like it's safe to push -rc3 into rawhide. The worst case scenario >> would be an ABI change -rc4 or the final release that we force us to >> patch LLVM to maintain compatibility with the -rc3 ABI. This scenario >> would not require rebuilding LLVM library users in Fedora, so this >> would not require much extra work from our team. >> >> Updates after 18.0.0-rc3 will generally be very small and can be done >> after the Final Freeze is over. If we are late packaging release >> candidates after -rc3 or the final release, we will not ask for a >> Final Freeze exception, unless they contain a fix for a critical >> release blocking bug. >> >> == Feedback == >> > > This came in while I was on PTO, so my apologies for the late reply on it. > > My concern here is with the timing and its inclusion into Fedora ELN > (and, by extension, CentOS Stream 10). The public plan for CS 10 is > that it will break inheritance from Fedora Rawhide/ELN at the Fedora > 40 branch point (Feb. 6th). By the schedule you've listed here, that > means this Change will land in Fedora after we branch, which will > likely mean that this (not-inconsiderable) effort will need to be > replicated in the CentOS Stream 10 environment, rather than being > simply inherited through Fedora ELN. Once the proposed Bodhi update > arrives during Beta Freeze, it will be picked up by Fedora ELN... but > at that point ELN will be tracking RHEL/CentOS Stream 11. Without committing anything on their behalf -- I expect this will not be the final LLVM for CS 10 anyway. We've been rebasing LLVM every 6 months in CS and RHEL (like Rust and Go), and looking back you can see that CS9 also had different LLVM versions between beta and GA. > I'm not sure this is an avoidable situation, given the upstream > release schedule, but I want to make sure we call it out so you can > prepare for it. > -- > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
