LLVM 18 is an Accepted Fedora 40 change [0]. We may consider pulling it in for the Beta release during the Beta Freeze if it is built sufficiently early in the freeze process. Pulling it earlier may ease burden on the developers, QA and other parties that may come with pulling the change in after the beta release. On the other hand, such having the builds done late may increase risks of destabilizing the Beta release process. As this moment, the builds are in progress for Rawhide. [0] https://fedoraproject.org/wiki/Changes/LLVM-18
Discussed during the 2024-02-26 blocker review meeting: [1] The decision to classify this bug wasn't made: "The decision was delayed, let's see when the builds are ready and decide how far we are in the freeze by that point." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-26/f40-blocker-review.2024-02-26-17.01.log.html
FEDORA-2024-fadeea3975 (glslang-14.0.0-1.fc40, shaderc-2023.8-1.fc40, and 8 more) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-fadeea3975
This was discussed at today's blocker/FE review meeting - https://meetbot-raw.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-03-04/f40-blocker-review.2024-03-04-17.00.html - and FESCo meeting - https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-04/fesco.2024-03-04-19.30.html . Ultimately FESCo agreed to let it land late, and an FE was granted.
FEDORA-2024-fadeea3975 (glslang-14.0.0-1.fc40, shaderc-2023.8-1.fc40, and 8 more) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
I'm confused, the linked bodhi update doesn't seem to be for llvm?
Nikita, I think these packages are required by packages that will be rebuilt with the new LLVM.
Yeah, sorry, I mentioned it on the stable push request ticket but should've mentioned it here too. František said that update is a necessary precursor to the actual LLVM 18 update, which is why it was marked as related to this bug report but not as *closing* it. I'm expecting that now that one is stable, František will submit the actual LLVM 18 update soon. Good to know somebody is paying attention to the process, too!
FEDORA-2024-bde3811225 (clang17-17.0.6-6.fc40, clang-18.1.0~rc4-2.fc40, and 18 more) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-bde3811225
FEDORA-2024-bde3811225 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-bde3811225` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-bde3811225 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I left a comment about this on the update but I figure it's worth leaving here as well since it's marked as pending stable: The llvm18 update breaks the compiler setup for ROCm. We knew that llvm18 was going to be a problem and the plan was to move over to the llvm17 packages but it turns out that there are issues with the compiler-rt17 package which is needed for ROCm to build and the ROCm bits that were built in rawhide against the llvm17 don't work [1]. There haven't been any changes in that package since branch so the same issue will show up in F40 but we can do F40 builds as well if that is needed. There isn't a rhbz for this issue yet but the llvm folks are aware of the problem and, as far as I know, are working on a fix. [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2416103
Whut? What happened to the complete deadline? "Change accepted" still requires the change to be testable in time. Has there been any testing of affected packages yet? Are you going to fix the fall out? Here is one: https://koji.fedoraproject.org/koji/taskinfo?taskID=114613227 There is no python-clang17 to switch to as a quick fix (contrary to what the change proposal seems to have indicated).
> Whut? What happened to the complete deadline? The Change was approved with late landing baked in. See step 9 at https://fedoraproject.org/wiki/Changes/LLVM-18#Plan . Because of this, FESCo decided during their meeting on Monday that it was still fine for this to go in now.
(In reply to Michael J Gruber from comment #12) > Whut? What happened to the complete deadline? > > "Change accepted" still requires the change to be testable in time. Has > there been any testing of affected packages yet? Are you going to fix the > fall out? Here is one: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=114613227 > > There is no python-clang17 to switch to as a quick fix (contrary to what the > change proposal seems to have indicated). Can you help me parse this log, which error in here do you think is related to the clang update?
(In reply to Tom Stellard from comment #14) > (In reply to Michael J Gruber from comment #12) > > Whut? What happened to the complete deadline? > > > > "Change accepted" still requires the change to be testable in time. Has > > there been any testing of affected packages yet? Are you going to fix the > > fall out? Here is one: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=114613227 > > > > There is no python-clang17 to switch to as a quick fix (contrary to what the > > change proposal seems to have indicated). > > Can you help me parse this log, which error in here do you think is related > to the clang update? mupdf creates c++ and python bindings using python-clang/swig. The same spec built fine on rawhide a few days ago and still does on f40. (I also build mupdf from git every few days, same effect there.) clang17 vs clang18 is the only change I can attribute this to. What happens is that now on rawhide, most function wrappers are not created: https://bugs.ghostscript.com/show_bug.cgi?id=707646
Just to be sure, I compared passing and failing copr builds (2 days time difference). Among packages installed into the buildroot, the only differences are: forge-srpm-macros 0.2.0-3.fc40 vs 0.3.0-1.fc41 python3-clang 17.0.6-6.fc40 vs 18.1.0~rc4-2.fc41 clang 17.0.6-6.fc40 vs 18.1.0~rc4-2.fc41 (plus subpackages, llvm, llvm-libs) cmake-filesystem 3.28.2-1.fc40 vs 3.28.3-1.fc41 And that is why I "blamed" clang18. (It may very well be that mupdf's mupdfwrapper.py does things it shouldn't do and which break with 18.)
I'm not sure why, but adding BuildRequires: clang17 fixes the build when I tested it. I'm going to keep investigating to see why this is.
(In reply to Tom Stellard from comment #17) > I'm not sure why, but adding BuildRequires: clang17 fixes the build when I > tested it. I'm going to keep investigating to see why this is. So, python-clang from clang18 uses clang17 when present? Maybe mupdf's wrapper script does something funny, Artifex tend to do their own thing. In any case, BR'ing clang17 is a good hot fix in case things don't get resolved otherwise. Thanks!
(In reply to Tom Stellard from comment #17) > I'm not sure why, but adding BuildRequires: clang17 fixes the build when I > tested it. I'm going to keep investigating to see why this is. Sorry, this should be BuildRequires: clang17-devel
The ROCM fix is in the update now (clang17-17.0.6-7.fc40).
(In reply to Tom Stellard from comment #19) > (In reply to Tom Stellard from comment #17) > > I'm not sure why, but adding BuildRequires: clang17 fixes the build when I > > tested it. I'm going to keep investigating to see why this is. > > Sorry, this should be BuildRequires: clang17-devel Yes, and just looking at "dnf repoquery -l", I see a surprisingly long list of (header and cmake) files which are there in clang17-devel and missing in clang18-devel (clang-devel-18...). Their content might be subsumed somewhere else, of course. I dunno about that. But it's consistent with the observation that pulling in clang17-devel makes the build work. Are there any major deprecations in clang18, or have the missing files been "internal use" before already?
I've rebuilt clang locally (f40 mock) with clang from dist-git at that commit: bec3936 ("Include the same content in the compat packages as we do in the main package", 2024-02-17) This clang-devel (17) is missing the same files which clang-devel (18) is missing compared to the compat package clang17-devel. Hint hint ... ;-)
Can this update be pushed to stable? Are we waiting on anything else?
(In reply to Tom Stellard from comment #24) > Can this update be pushed to stable? Are we waiting on anything else? It breaks stuff (mupdf) that can be unbroken by BR'ing clang17-devel. This is a workaround, not a fix, but need not hold up clang 18 where clang17 is available. I assume we'll have clang17 at the time clang is updated to 18, right? I've investigated further, btw. mupdf's FTBFS with clang 18 is not an issue of different header files (and I was wrong about their extent - wrong diff or boot(s)trap issue). In a rawhide mock chroot, I can install all mupdf BRs plus clang17-devel (and its dependencies), then remove all files from those clang17-devel etc. except for the actual library so's, and mupdf still builds. So the problem has to be some specific behaviour which changed in clang 18 and which makes mupdf's mupdfwrapper fail to create the sources for the bindings.
(In reply to Michael J Gruber from comment #25) > (In reply to Tom Stellard from comment #24) > > Can this update be pushed to stable? Are we waiting on anything else? > > It breaks stuff (mupdf) that can be unbroken by BR'ing clang17-devel. This > is a workaround, not a fix, but need not hold up clang 18 where clang17 is > available. I assume we'll have clang17 at the time clang is updated to 18, > right? > Yes, clang17 will still be available.
We've been including it in the Beta candidate composes but not pushing it stable because I didn't really want it to disrupt builds of anything else during the freeze, in case we needed to build something to fix a blocker or FE and this happened to break it...I was planning to keep doing that till we have a signed-off Beta, then push it stable with the 0-day push.
@awilliam OK, sounds good, thanks.
@mjg Here is a fix for mupdf: https://src.fedoraproject.org/rpms/mupdf/pull-request/6
Thanks for the fix. (Details discussed there.) About the needinfo: Do you need me to merge this now to (rawhide and) F40 so that you can amend the side-tag before the push? If yes I'll do. Otherwise I might give Artifex another day for their upstream patch.
FEDORA-2024-bde3811225 (clang17-17.0.6-7.fc40, clang-18.1.0~rc4-2.fc40, and 19 more) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.