build: Bump clang minimum supported version to 15 #29165
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.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. 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. |
maflcko
force-pushed
the
2401-clang-15-
branch
from
b08682d
to
eac1a46
Compare
|
The macOS CI fails (as expected). Moving to draft for now, until someone clarifies the macOS clang situation. (I don't use macOS) |
Xcode 14.3.1 (currently used in the CI) is based on ~ LLVM 14. It's failing because removing the fuzz workaround requires LLVM/Clang 15 or later. The GH image ships with newer Xcodes, https://github.com/actions/runner-images/blob/main/images/macos/macos-13-Readme.md#xcode, so I assume we could switch to using Xcode 15.x + in the CI (based on LLVM 16.x). The multiprocess build is also failing, due to what I assume is a Debian packaging issue. |
|
The libbitcoinkernel |
maflcko
force-pushed
the
2401-clang-15-
branch
from
eac1a46
to
7825898
Compare
maflcko
force-pushed
the
2401-clang-15-
branch
from
7825898
to
e58e752
Compare
maflcko
force-pushed
the
2401-clang-15-
branch
7 times, most recently
from
7acb570
to
fa88791
Compare
maflcko
force-pushed
the
2401-clang-15-
branch
from
fa88791
to
fa224a2
Compare
f8ca135 build: Fix check whether `-latomic` needed (Hennadii Stepanov) Pull request description: Clang >=15 still might need linking against `libatomic`. We use `std::atomic<std::chrono::seconds>::compare_exchange_strong` in `net_processing.cpp`. Addresses the bitcoin/bitcoin#29165 (comment). ACKs for top commit: maflcko: lgtm ACK f8ca135 fanquake: ACK f8ca135 Tree-SHA512: ba8b6a88fd3471a206d068e8a000a053c99cb46d26bd04624418ddb066b3b9664a569ec8a1569af67c96b3e27f13dccbd5e24f985290ac072b6d74c92524e35d
|
Can you add a note to My Intel iMac from 2017 runs macOS 13.6.6 and has clang 15.0.0. It's installed at Xcode 14.3.1 and newer ship with clang 15.0: The system requirements for that is macOS Ventura 13.0 or later: https://developer.apple.com/documentation/xcode-release-notes/xcode-14_3_1-release-notes# Homebrew itself officially supports macOS 12 or later, but may still work on macOS 11: https://docs.brew.sh/Installation Fwiw macOS 11 Big Sur last got an update in September 2023, so Apple has not entirely written it off: https://en.wikipedia.org/wiki/MacOS_Big_Sur |
##29918 is an unrelated issue existing on current master, so I think a separate pull request would be more appropriate. Also, I don't have or use macOS/Apple, so someone else creating that pull request would be beneficial. |
|
My remark is orthogonal to #29918. macOS < 13 doesn't have clang 15. They also don't have clang 14, which was missed in #29208. There's need to make a separate pull request for a single sentence: At the bottom of step 3: On macOS < 13 you additionally need to install a more recent version of clang:
brew install clang |
I don't think this is enough. Is it not required to specify the CC and CXX to Another reason to fix this in a separate pull is to have the fix in before this pull is merged (which at this point is unclear when it can happen). |
|
Done in #29934. Correction to version support above: clang 15.0 is shipped with Xcode 15, not 14. But its system requirements are fairly similar, macOS 13.5 or better: https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes I don't have a macOS 11 or 12 machine to actually test if it still works. Given that homebrew dropped explicit support for macOS 11 I don't think we need to worry about that version, but it would be nice if someone can test if they can still build (clang 15) on macOS 12. |
|
Thanks, I'll rebase once the other pull is merged. |
|
Rebased and taken out of draft. I've opened two pull requests against oss-fuzz to bump the compiler there (one globally and one for bitcoin-core), but they are waiting for merge. If they are not merged, I think we can consider oss-fuzz as unsupported and drop it temporarily. Oss-fuzz is nice, but it seems odd to consider it a blocker here. |
|
Yea. I think we can merge our independant oss-fuzz bump, then merge this, then revert the oss-fuzz change if/when the global oss-fuzz bump happens. That has dragged on a bit too long, and is just blocking things here. |
8fd40d4 fixup! ci: Test CMake edge cases (Hennadii Stepanov) c08acdb fixup! ci: Test CMake edge cases (Hennadii Stepanov) Pull request description: See bitcoin#29165. ACKs for top commit: m3dwards: utACK 8fd40d4 Tree-SHA512: 4f74730de2de7767875357044763f9aa73ba0e973a9af2572989f51bf631cd082279f08b7141ef8e56765cecf327ee31406bd83d05eb2a5125d520f773d0210f
Most supported operating systems ship with clang-15 (or later), so bump the minimum to that and allow new code to drop workarounds for previous clang bugs.
For reference:
clang17); No idea about OpenSuse LeapOn operating systems where the clang version is not shipped by default, the user would have to use GCC, or install clang in a different way. For example: