releases: use LLVM 18 for macOS #30022
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
| else | ||
| $(package)_file_name=clang+llvm-$($(package)_version)-x86_64-linux-gnu-ubuntu-22.04.tar.xz | ||
| $(package)_sha256_hash=884ee67d647d77e58740c1e645649e29ae9e8a6fe87c1376be0f3a30f3cc9ab3 | ||
| $(package)_file_name=clang+llvm-$($(package)_version)-x86_64-linux-gnu-ubuntu-18.04.tar.xz |
There was a problem hiding this comment.
this download link works but ubuntu-18?
There was a problem hiding this comment.
this download link works but ubuntu-18?
This should be fixed in LLVM 19: https://discourse.llvm.org/t/rfc-improve-binary-security/78121/56
There was a problem hiding this comment.
Yea. While using the pre-built bins, we have to take what is available. For some reason the person building the x86_64 bins here has reverted to that. It also means we'll need to revert to installing libtinfo5 in the macOS CI, which is also annoying, because you also can't actually install that on Ubuntu 24.04 (although we currently still use 22.04 here, so it'll work for now).
There was a problem hiding this comment.
Or waiting after #21778, which should be fine as well, as there is no rush to use clang 18?
There was a problem hiding this comment.
It should be possible now to nuke this and require the user (if they want to cross-compile to macOS) to type apt install clang-18 instead?
I presume leaving this to the user will allow to run the cross-compile on more distros and arches, as opposed to being possibly confined to x86_64-linux-gnu-ubuntu when using the llvm artefacts?
There was a problem hiding this comment.
Yea, the plan is to switch away from vendoring Clang entirely, which is more straightforward now that #21778 is merged. I'll be followingup.
fanquake
force-pushed
the
macos_llvm_18_releases
branch
from
857130c
to
6170706
Compare
fanquake
force-pushed
the
macos_llvm_18_releases
branch
2 times, most recently
from
1246dfc
to
0b01a0f
Compare
Patch Qts internal libpng to resolve the failure.
Version is 18.1.6.
fanquake
force-pushed
the
macos_llvm_18_releases
branch
from
0b01a0f
to
9170786
Compare
Bumps the Guix time-machine to include a bump to LLVM 18.1.6: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1fa1325c0b4bb5c28e564526f387d82083733104. Can split this out given it effects all releases.
Needs another patch to Qt. It's internal libpng build is broken with the newer Clang, due to:
See https://releases.llvm.org/18.1.0/tools/clang/docs/ReleaseNotes.html?1=#clang-frontend-potentially-breaking-changes.