build: use native clang as darwin compiler #618
Conversation
as unknown warning option for clang
bitcoin/bitcoin#16730 Without this fix we got a following error: no member named 'Serialize' in 'std::__1::__bit_const_reference<std::__1::vector<bool, std::__1::allocator<bool> > >' during clang build.
both arguments here considered as unsigned int as 0 was 0U and taking the max of unsigned zero and a value is always equal to the other value.
|
Seems we have similar issue boostorg/lexical_cast#49 here. Additionally, this issue does not occur with p.s. Possible solutions:
Before proceeding, we need to decide on the specific approach we will take. |
Would the logical path forward not be to update the min version of Xcode to something newer than 4 years old and the SDK to something newer than 2019? (Xcode 11.3.1 release date: 13 Jan 2020 -- Catalina [10.15.1] End of Life: 12 Sep 2022) Why is time and resources being allocated to making the code older than even the OS companies support? Is there some logical reason that we observers are missing that justifies not making things for the future rather than so old that no one supports them? |
Thank you for your concern, but we are already using fresh version of XCode in our Mac CI. As you can see, we are using the macos-latest image for the runner, which includes XCode 14.2 by default.
However, this behavior may change because we are creating static binaries that are intended to work on most versions of macOS, including macOS Monterey (version 12). |
DeckerSU
force-pushed
the
patch-macos-build-clang
branch
from
d2f29f3
to
11a0138
Compare
This reverts commit 728f74a.
|
this might help to see what packages are being dealt with on the runners: |
|
And ... this is indeed funny, in last commit I added the following to the build script: komodo/zcutil/build-mac-dtest.sh Lines 56 to 61 in dfd0e2b To view the executable file headers right after build. And you know what i saw in logs: It means that right after build |
I appreciate your assistance, but the problem does not lie in the software versions. It appears that the binaries are building fine on the runner. The issue with the zeroized |
|
Solved! I spent a significant amount of time on this.
Image have 2 versions of
The first one breaking the files. |
|
After utilizing |
|
given that upload-artifact has its own compression mechanism, what's the reasoning for doing any of that rather than utilizing the functions of the action already in use? (ie, why tar it at all?)
|
Ask the person who initially wrote this workflow 😄 I will not modify this behavior since other parts of the workflow rely on |
I guess that would beg the question: Why are we still using I guess the tl;dr of my questions is: It's kind of like seeing someone bash their head against a wall trying to break through it, asking them "why aren't you using the door", and their reply being "Well, I already started this, I might as well continue doing it". |
|
Following the Device/OS: MacMini / MacOS Sonoma 14.6.1
Continuing with the README, build fails with error below: |
Although your report doesn't contain the exact error that prevents Boost from building on your system, it's clear that you can't build this branch on Sonoma. This branch was created before Sonoma's release on September 26, 2023, so it's expected that it might not compile with the latest macOS. However, the successor of this branch, |
This pull request switches the compiler for
darwinfromgccto nativeclang. However, this branch is based on thepatch-remove-libsnarkbranch. Therefore, if we decide to accept it, we should first accept #613 and then merge this pull request.