build: Bump clang minimum supported version to 15 #29165

pull maflcko wants to merge 1 commits into bitcoin:master from maflcko:2401-clang-15- changing 2 files +4 −4
  1. maflcko commented at 11:03 am on January 2, 2024: member

    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:

    On 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:

  2. DrahtBot commented at 11:03 am on January 2, 2024: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Code Coverage

    For detailed information about the code coverage, see the test coverage report.

    Reviews

    See the guideline for information on the review process.

    Type Reviewers
    ACK hebasto, fanquake

    If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #29077 ([WIP, DO NOT MERGE!!11111!!!!!] build: Require libc++-16 or later by maflcko)
    • #29071 (refactor: Remove Span operator==, Use std::ranges::equal by maflcko)
    • #28687 (C++20 std::views::reverse by stickies-v)
    • #25972 (build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set by fanquake)

    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.

  3. DrahtBot added the label Build system on Jan 2, 2024
  4. maflcko force-pushed on Jan 2, 2024
  5. hebasto commented at 11:13 am on January 2, 2024: member

    Related:

  6. maflcko commented at 11:30 am on January 2, 2024: member
    The macOS CI fails (as expected). Moving to draft for now, until someone clarifies the macOS clang situation. (I don’t use macOS)
  7. maflcko marked this as a draft on Jan 2, 2024
  8. fanquake commented at 11:47 am on January 2, 2024: member

    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.

  9. fanquake commented at 11:50 am on January 2, 2024: member
    The libbitcoinkernel clang-15 libc++ job is also failing, so I guess this isn’t actually fixed with clang-15, regardless of macOS?
  10. maflcko force-pushed on Jan 2, 2024
  11. DrahtBot added the label CI failed on Jan 2, 2024
  12. maflcko force-pushed on Jan 2, 2024
  13. in .github/workflows/ci.yml:93 in e58e752aae outdated 
    88@@ -89,7 +89,9 @@ jobs:
89         uses: actions/checkout@v4
90 
91       - name: Clang version
92-        run: clang --version
93+        run: |
94+          xcode-select --switch "/Applications/Xcode15.1.app"
    hebasto commented at 12:04 pm on January 2, 2024: 
    0          sudo xcode-select --switch "/Applications/Xcode15.1.app"
    fanquake commented at 12:06 pm on January 2, 2024:
    If any version is going to be picked, shouldn’t it be the one we use for releases?
    hebasto commented at 12:07 pm on January 2, 2024:
    Or sudo xcode-select -switch /Applications/Xcode_15.1.app. It works in https://github.com/hebasto/bitcoin/actions/runs/7385516810/job/20090426555
    fanquake commented at 12:08 pm on January 2, 2024:

    Run sudo xcode-select –switch “/Applications/Xcode15.1.app” xcode-select: error: invalid developer directory ‘/Applications/Xcode15.1.app’

    hebasto commented at 12:47 pm on January 2, 2024:

    If any version is going to be picked, shouldn’t it be the one we use for releases?

    Xcode 15.0.1 (15A507) and 15.1 (15C65) versions are available now, and they are subjects for frequent updates.

    fanquake commented at 12:51 pm on January 2, 2024:

    Xcode 15.0.1 (15A507) and 15.1 (15C65) versions are available now,

    My suggestion was to pick 15.0, which we use for release builds, so that CI better matches our release process, rather than 15.1, as you suggested. Otherwise code could compile in the CI, but not in Guix.

    maflcko commented at 1:06 pm on January 2, 2024:
    Looks like the macOS CI now fails for unrelated reasons. If someone created a separate pull request to bump xcode in the macOS CI, that’d be great.
    hebasto commented at 9:28 pm on January 2, 2024:

    Looks like the macOS CI now fails for unrelated reasons. If someone created a separate pull request to bump xcode in the macOS CI, that’d be great.

    The underlying issue is that Apple Clang 15 does not support -Xclang -internal-isystem anymore. Therefore, supporting for the --enable-suppress-external-warnings option on x86_64 macOS becomes a non-trivial task.

    maflcko commented at 9:31 am on January 3, 2024:

    For reference, the error is https://github.com/bitcoin/bitcoin/actions/runs/7387978338/job/20097842474?pr=29165#step:7:2150

    0 /usr/local/include/event2/event.h:838:10: error: parameter 'tv' not found in the function declaration [-Werror,-Wdocumentation] [@param](/bitcoin-bitcoin/contributor/param/) tv the amount of time after which the loop should terminate,
1         ^~
2fatal error: too many errors emitted, stopping now [-ferror-limit=]
320 errors generated.
4make[2]: *** [bitcoin_cli-bitcoin-cli.o] Error 1
5make[1]: *** [install-recursive] Error 1
6make: *** [install-recursive] Error 1
    hebasto commented at 9:45 am on January 3, 2024:
    Right, the event2/event.h is no longer considered as a system header, which allows a compiler to emit warnings from it, even configured with the --enable-suppress-external-warnings option .
    hebasto commented at 9:47 am on January 3, 2024:
    We could pass -nostdinc to the compiler and specify include ditrectories explicitly. However, such a solution looks a bit ugly to me.
    maflcko commented at 9:48 am on January 3, 2024:
    IIUC this should affect everyone on macOS today already on current master, using clang-15, so a separate issue and bugfix can be filed?
    fanquake commented at 10:07 am on January 3, 2024:

    The underlying issue is that Apple Clang 15 does not support -Xclang -internal-isystem anymore.

    I’d be very suprised if this was the case, given it’s a core Clang flag? Even more suprised if they’d for some reason only removed it for x86_64?

    hebasto commented at 10:11 am on January 3, 2024:

    The underlying issue is that Apple Clang 15 does not support -Xclang -internal-isystem anymore.

    I’d be very suprised if this was the case, given it’s a core Clang flag? Even more suprised if they’d for some reason only removed it for x86_64?

    https://github.com/bitcoin/bitcoin/actions/runs/7395607754/job/20119092833:

    0checking whether C++ preprocessor accepts -Xclang -internal-isystem/usr/local/include... no
    hebasto commented at 10:49 am on January 3, 2024:

    Here are excerpts from config.log:

    • Apple clang version 14.0.3 (clang-1403.0.22.14.1):
    0configure:23855: checking whether C++ preprocessor accepts -Xclang -internal-isystem/usr/local/include
1configure:23875: g++ -std=c++20 -E  -Werror -Xclang -internal-isystem/usr/local/include conftest.cpp
2configure:23875: $? = 0
3configure:23885: result: yes
    • Apple clang version 15.0.0 (clang-1500.0.40.1):
    0configure:23855: checking whether C++ preprocessor accepts -Xclang -internal-isystem/usr/local/include
1configure:23875: g++ -std=c++20 -E  -Werror -Xclang -internal-isystem/usr/local/include conftest.cpp
2error: unknown argument: '-internal-isystem/usr/local/include'
    maflcko commented at 11:58 am on January 3, 2024:
    Again, this should affect everyone on macOS today already on current master, using clang-15 (or later), so a separate issue and bugfix can be filed?
    hebasto commented at 9:55 am on January 4, 2024:

    Again, this should affect everyone on macOS today already on current master, using clang-15 (or later), so a separate issue and bugfix can be filed?

    See #29174.

    maflcko commented at 9:59 am on January 4, 2024:
    Thanks, resolving discussion here for now
  14. maflcko force-pushed on Jan 2, 2024
  15. maflcko force-pushed on Jan 2, 2024
  16. maflcko force-pushed on Jan 2, 2024
  17. maflcko force-pushed on Jan 2, 2024
  18. maflcko force-pushed on Jan 2, 2024
  19. maflcko force-pushed on Jan 2, 2024
  20. maflcko force-pushed on Jan 2, 2024
  21. DrahtBot removed the label CI failed on Jan 2, 2024
  22. maflcko marked this as ready for review on Jan 3, 2024
  23. maflcko force-pushed on Jan 3, 2024
  24. in ci/test/00_setup_env_i686_multiprocess.sh:16 in fa224a25c7 outdated 
    14+export PACKAGES="cmake llvm clang libclang-rt-dev g++-multilib"
15 export DEP_OPTS="DEBUG=1 MULTIPROCESS=1"
16 export GOAL="install"
17 export BITCOIN_CONFIG="--enable-debug CC='clang -m32' CXX='clang++ -m32' \
18-LDFLAGS='--rtlib=compiler-rt -lgcc_s' CPPFLAGS='-DBOOST_MULTI_INDEX_ENABLE_SAFE_MODE'"
19+LDFLAGS='-latomic --rtlib=compiler-rt -lgcc_s' CPPFLAGS='-DBOOST_MULTI_INDEX_ENABLE_SAFE_MODE'"
    fanquake commented at 10:27 am on January 3, 2024:

    Does our -latomic check no-longer work, because that should be adding this if needed? According to the docs this should no-longer be needed with clang-15?

    Clang prior to version 15, when building for 32-bit, and linking against libstdc++, requires linking with -latomic if using the C++ atomic library.

    We should probably either fixup the check, or fixup the docs, or both.

    maflcko commented at 11:56 am on January 3, 2024:

    Sure, but that happens today on current master, unrelated to the changes in this pull request. So it seems best to create a separate issue and fix for this.

    Left a comment here: https://github.com/bitcoin/bitcoin/pull/28777/files#r1440369992

    fanquake commented at 12:49 pm on January 3, 2024:

    Sure, but that happens today on current master, unrelated to the changes in this pull request.

    No? The addition of -latomic here, is only needed with the changes in this PR. Otherwise CI on master would be failing.

    maflcko commented at 1:13 pm on January 3, 2024:
    Sorry, I meant fixing/changing the latomic build system check is unrelated, not the CI changes in this PR.
    hebasto commented at 11:51 am on January 4, 2024:
    Please see #29177.
    maflcko commented at 10:54 am on January 5, 2024:
    Thanks, fixed.
  25. fanquake referenced this in commit c80f57ba57 on Jan 5, 2024
  26. maflcko force-pushed on Jan 5, 2024
  27. maflcko force-pushed on Jan 5, 2024
  28. hebasto approved
  29. hebasto commented at 11:24 am on January 5, 2024: member
    ACK fac4cf24588c281b12f9f64aa6f0a4dda1a645b7.
  30. maflcko commented at 1:59 pm on January 5, 2024: member

    Just tested #28657 on oss-fuzz:

     0  AR       libbitcoin_util.a
 1  AR       libbitcoin_consensus.a
 2  CXXLD    crypto/libbitcoin_crypto_base.la
 3  CXXLD    crypto/libbitcoin_crypto_sse41.la
 4  CXXLD    crypto/libbitcoin_crypto_avx2.la
 5  CXXLD    crypto/libbitcoin_crypto_x86_shani.la
 6  AR       libbitcoin_cli.a
 7  CXXLD    libunivalue.la
 8  CXXLD    crc32c/libcrc32c.la
 9  CXXLD    leveldb/libmemenv.la
10  AR       minisketch/libminisketch.a
11  CXXLD    leveldb/libleveldb.la
12  CXXLD    test/fuzz/fuzz
13/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25
14/tmp/lto-llvm-e81dca.o: in function `(anonymous namespace)::TestNode(miniscript::MiniscriptContext, std::__1::shared_ptr<miniscript::Node<CPubKey> const> const&, FuzzedDataProvider&)':
15miniscript.cpp:(.text._ZN12_GLOBAL__N_18TestNodeEN10miniscript17MiniscriptContextERKNSt3__110shared_ptrIKNS0_4NodeI7CPubKeyEEEER18FuzzedDataProvider[_ZN12_GLOBAL__N_18TestNodeEN10miniscript17MiniscriptContextERKNSt3__110shared_ptrIKNS0_4NodeI7CPubKeyEEEER18FuzzedDataProvider]+0x420): undefined reference to `miniscript::operator"" _mst(char const*, unsigned long)'
16/usr/bin/ld: /tmp/lto-llvm-e81dca.o: in function `std::__1::shared_ptr<miniscript::Node<CPubKey> const> (anonymous namespace)::GenNode<miniscript_stable_fuzz_target(Span<unsigned char const>)::$_1>(miniscript::MiniscriptContext, miniscript_stable_fuzz_target(Span<unsigned char const>)::$_1, miniscript::Type, bool)':
17miniscript.cpp:(.text._ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb[_ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb]+0x520): undefined reference to `miniscript::operator"" _mst(char const*, unsigned long)'
18/usr/bin/ld: miniscript.cpp:(.text._ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb[_ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb]+0x6b2): undefined reference to `miniscript::operator"" _mst(char const*, unsigned long)'
19/usr/bin/ld: miniscript.cpp:(.text._ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb[_ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb]+0x6cc): undefined reference to `miniscript::operator"" _mst(char const*, unsigned long)'
20/usr/bin/ld: miniscript.cpp:(.text._ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb[_ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb]+0x746): undefined reference to `miniscript::operator"" _mst(char const*, unsigned long)'
21/usr/bin/ld: /tmp/lto-llvm-e81dca.o:miniscript.cpp:(.text._ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb[_ZN12_GLOBAL__N_17GenNodeIZ29miniscript_stable_fuzz_target4SpanIKhEE3$_1EENSt3__110shared_ptrIKN10miniscript4NodeI7CPubKeyEEEENS7_17MiniscriptContextET_NS7_4TypeEb]+0x8cb): more undefined references to `miniscript::operator"" _mst(char const*, unsigned long)' follow
22clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
23make[2]: *** [Makefile:7755: test/fuzz/fuzz] Error 1
24make[2]: Leaving directory '/src/bitcoin-core/src'
25make[1]: *** [Makefile:20277: all-recursive] Error 1
26make[1]: Leaving directory '/src/bitcoin-core/src'
27make: *** [Makefile:808: all-recursive] Error 1
28ERROR:__main__:Building fuzzers failed.

    via:

     0diff --git a/projects/bitcoin-core/build.sh b/projects/bitcoin-core/build.sh
 1index cd3ec7e73..566ce6ed8 100755
 2--- a/projects/bitcoin-core/build.sh
 3+++ b/projects/bitcoin-core/build.sh
 4@@ -15,10 +15,11 @@
 5 #
 6 ################################################################################
 7 
 8-$SRC/build_cryptofuzz.sh
 9 
10 cd $SRC/bitcoin-core/
11 
12+git fetch origin 190fa2a95b7daf34afcf9ddeefb99d6efba463ea
13+git checkout 190fa2a95b7daf34afcf9ddeefb99d6efba463ea
14 # Build dependencies
15 # This will also force static builds
16 if [ "$ARCHITECTURE" = "i386" ]; then
  31. maflcko marked this as a draft on Jan 5, 2024
  32. hebasto commented at 12:02 pm on January 7, 2024: member

    If someone created a separate pull request to bump xcode in the macOS CI, that’d be great.

    Please see #29195.

  33. fanquake referenced this in commit 9e1306fc88 on Jan 9, 2024
  34. maflcko force-pushed on Jan 9, 2024
  35. in .github/workflows/ci.yml:114 in fa5ddff539 outdated 
    109@@ -110,6 +110,8 @@ jobs:
110           restore-keys: ${{ github.job }}-ccache-
111 
112       - name: CI script
113+        env:
114+          NO_WERROR: 1  # Work around https://github.com/bitcoin/bitcoin/issues/29174
    hebasto commented at 10:57 am on January 9, 2024:
    Might be dropped now.
    maflcko commented at 10:58 am on January 9, 2024:
    thx, done
  36. maflcko force-pushed on Jan 9, 2024
  37. theuni commented at 12:07 pm on January 9, 2024: member

    From what I can tell, we shouldn’t need this after clang-14: https://github.com/bitcoin/bitcoin/blob/master/build-aux/m4/bitcoin_runtime_lib.m4

    Is that the case?

    Noticed while reviewing https://github.com/hebasto/bitcoin/pull/43/commits/910fd7a64802380fe912446cd3c938d56e470f0b#diff-b937c829d4a0cf9a653f5361656ea8196b6ecef40fd033aa41a6da945e987bcdR146 @maflcko Can we just skip porting that to CMake, or am I missing something?

  39. fanquake commented at 12:52 pm on January 9, 2024: member

    Should I change this pull to bump to 14 instead, and remove the m4 file?

    Why change to 14, and not just add the m4 removal to this PR?

  40. maflcko commented at 12:55 pm on January 9, 2024: member

    Why change to 14, and not just add the m4 removal to this PR?

    Oss-Fuzz is on clang-14, so a later version can not be used, for now. See #29165 (comment)

  41. fanquake commented at 1:00 pm on January 9, 2024: member

    Oss-Fuzz is on clang-14,

    I was always under the impression it was 15: https://github.com/google/oss-fuzz/blob/6c19a0f229c244d41562ece92f9baac6b72426f9/infra/base-images/base-clang/checkout_build_install_llvm.sh#L53

    OUR_LLVM_REVISION=llvmorg-15-init-1464-gbf7f8d6f

  42. fanquake commented at 1:03 pm on January 9, 2024: member

    Looking at a recent build of a project on oss-fuzz: https://github.com/google/oss-fuzz/actions/runs/7449538792/job/20266395883#step:7:283

    – The C compiler identification is Clang 15.0.0

  43. maflcko commented at 1:04 pm on January 9, 2024: member

    That version number is bumped after the branch-off, so any commit prior to clang 15, but after clang 14, also (incorrectly) identifies as clang 15.

    edit: If llvm used this repos’ versioning scheme, that version would be 14.99.

  44. DrahtBot added the label CI failed on Jan 9, 2024
  45. DrahtBot commented at 3:23 pm on January 9, 2024: contributor

    🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the documentation.

    Possibly this is due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

    Leave a comment here, if you need help tracking down a confusing failure.

    Debug: https://github.com/bitcoin/bitcoin/runs/20306279293

  46. maflcko commented at 3:32 pm on January 9, 2024: member
    @theuni See https://github.com/bitcoin/bitcoin/pull/29208
  47. DrahtBot added the label Needs rebase on Jan 11, 2024
  48. maflcko force-pushed on Jan 11, 2024
  49. DrahtBot removed the label Needs rebase on Jan 11, 2024
  50. DrahtBot removed the label CI failed on Jan 12, 2024
  51. maflcko force-pushed on Jan 12, 2024
  52. maflcko added this to the milestone 28.0 on Jan 12, 2024
  53. maflcko force-pushed on Mar 18, 2024
  54. maflcko force-pushed on Apr 1, 2024
  55. DrahtBot added the label CI failed on Apr 1, 2024
  56. maflcko removed this from the milestone 28.0 on Apr 10, 2024
  57. Sjors commented at 11:00 am on April 22, 2024: member

    Can you add a note to doc/build-osx.md that users of macOS < 13 need to install clang via homebrew?

    My Intel iMac from 2017 runs macOS 13.6.6 and has clang 15.0.0. It’s installed at /usr/bin/clang so not Homebrew.

    Xcode 14.3.1 and newer ship with clang 15.0: https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)

    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

  58. maflcko commented at 11:05 am on April 22, 2024: member

    Can you add a note to doc/build-osx.md that users of macOS < 13 need to install clang via homebrew?

    #https://github.com/bitcoin/bitcoin/issues/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.

  59. Sjors commented at 2:02 pm on April 22, 2024: member

    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:

    0On macOS < 13 you additionally need to install a more recent version of clang:
1
2    brew install clang
  60. maflcko commented at 2:10 pm on April 22, 2024: member

    There’s need to make a separate pull request for a single sentence:

    I don’t think this is enough. Is it not required to specify the CC and CXX to ./configure? Something like CC=$(brew --prefix llvm)/bin/clang CXX=$(brew --prefix llvm)/bin/clang++? Or does brew overwrite the clang system compiler?

    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).

  61. Sjors commented at 2:40 pm on April 22, 2024: member

    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.

  62. maflcko commented at 2:48 pm on April 22, 2024: member
    Thanks, I’ll rebase once the other pull is merged.
  63. maflcko marked this as ready for review on Apr 27, 2024
  64. build: Bump clang minimum supported version to 15 fa1964c5b8
  65. maflcko force-pushed on Apr 27, 2024
  66. hebasto approved
  67. hebasto commented at 1:29 pm on April 27, 2024: member
    ACK fa1964c5b80ee28b0e06abdbd9a26e8e8c6f5acd.
  68. maflcko commented at 2:37 pm on April 27, 2024: member
    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.
  69. DrahtBot removed the label CI failed on Apr 27, 2024
  70. fanquake commented at 2:08 am on April 29, 2024: member
    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.
  71. Sjors commented at 8:30 am on April 29, 2024: member
    @maflcko the updated wording in #29934 is such this PR won’t conflict with it.
  72. fanquake added the label Needs release note on Apr 29, 2024
  73. fanquake approved
  74. fanquake commented at 12:57 pm on April 29, 2024: member
    ACK fa1964c5b80ee28b0e06abdbd9a26e8e8c6f5acd - oss-fuzz LLVM will either be bumped globally tomorrow, or we’ll land our own bump.
  75. fanquake merged this on Apr 29, 2024
  76. fanquake closed this on Apr 29, 2024
  77. maflcko deleted the branch on Apr 29, 2024
  78. hebasto referenced this in commit 4561f7603f on Apr 29, 2024
  79. fanquake removed the label Needs release note on Jun 10, 2024
  80. fanquake commented at 1:27 pm on June 10, 2024: member
    Release note added in #30261.


maflcko DrahtBot hebasto fanquake theuni Sjors

Labels
Build system

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-23 09:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me