Thanks for this work, I think we could merge this out-of-phase to please the eye and avoid confusion - that's fine.

As for the license files, these will need to get changed, but I can work on that once this PR is done; don't worry about it for now.

PS: I noticed a regression on latest boost from brew on my M1 last week when I was doing a no depends build to test some of the ARM optimizations on 1.14.7-dev... am not sure yet what happened there yet, this is an open item for me right now.

Hi,

Would this be a rebase what it is now?

Thanks,
Victor.

Would this be a rebase what it is now?

Yes because all the CI changes are squashed into a UI commit. No worries, we'll get that done. For now just commit whatever you think is needed for now and when we're somewhere, I'll help cleaning it up.

Hi,

As far as image updates, I think I am done since my goal was to just change the splash screen. Most of the work now is to satisfy various CI Mac build requirements for Ventura. For example, I'm currently getting the error:

./fs.h:14:10: fatal error: 'boost/filesystem.hpp' file not found #include <boost/filesystem.hpp>

I tried to explicitly indicate header file location" --with-boost-libdir='/opt/homebrew/Cellar/boost/1.81.0_1/include'

But the error still showing up. Is there a way to set up CI environment locally so I can test changes locally? (I got this part going now) Perhaps I should use the -I to indicate location of boost header files?

P.S. I am happy this rebase went a little smoother than the first time I did, practice makes you perfect! 👍 😎

Thank you,
Victor.

Hi,

Some observations about last commit:

• I've added coreutils to brew install to fix test/functional/install-deps.sh: line 7: sha256sum: command not found configure error.
• I could be wrong on this but I think macOS 13.3 native task is failing right now because there are many -Werror compiler options set which treat warnings as errors and so configure phase keeps returning status 1.
• Is there a plan to switch 1.21-dev to a different "Continuous Integration" process? I see 1.14.7-dev is doing it a bit differently but haven't looked into it in great detail, do you plan for 1.21-dev to do the same as 1.14.7-dev or stay with the current CI implementation?

Thank you,
Victor.

Answering the easy one first:

Is there a plan to switch 1.21-dev to a different "Continuous Integration" process? I see 1.14.7-dev is doing it a bit differently but haven't looked into it in great detail, do you plan for 1.21-dev to do the same as 1.14.7-dev or stay with the current CI implementation?

Bitcoin's CI solution that we inherit with 1.21 is meant to be agnostic to platform (as much as can be) so it should be easy to switch platforms if so required. I think that the issues aren't with the platform but with our code. I'll spend some time on investigating this.

Bitcoin's CI solution that we inherit with 1.21 is meant to be agnostic to platform (as much as can be) so it should be easy to switch platforms if so required. I think that the issues aren't with the platform but with our code. I'll spend some time on investigating this.

Thank you for clarifying. I think I've resolved configure errors but now am getting the following error during compilation phase:

Undefined symbols for architecture arm64: "_getauxval", referenced from: ld: symbol(s) not found for architecture arm64 make[2]: *** [dogecoind] Error 1

That's with macOS 13.3 native [GOAL: install] [GUI] [no depends] task.

Hi,

Some notes about this last commit: 49b3fc1:

• To fix the arm64 compilation issue, I looked at howgetauxval is handled by Bitcoin and came across crc32c_arm64_check.h header file, which has a generic CanUseArm64Crc32() that seems to handle cases for both Linux and MacOS arm64 architectures. So I've copy-and-pasted relevant segment crc32c.cc to use this function instead and updated other affected files accordingly (probably crc32c_arm64_linux_check.h is redundant at this point). crc32c ("ARM-specific code checking for the availability of CRC32C instructions") seems to be used by Bitcoin also.
• The MacOS task is now compiling successfully, but is failing due to failed PSBT tests. I believe we encountered similar issue when working on Derivation path changes in 1.21-dev  #2977 but I can't remember what was done to circumvent this issue, did we disable PSBT tests?

Who could have thought that such trivial image change PR would lead to so many additional changes 😲

The MacOS task is now compiling successfully, but is failing due to failed PSBT tests.

Hmm no, it is failing due to berkdb 5.3 runtime issues - I suspect that this is similar to what I am seeing with 1.14.7-dev on BOTH arm64 and x86_64 Ventura. Compile and linking goes fine but at runtime it goes nuts.

2023-06-03T00:44:32.950525Z [test] BerkeleyEnvironment::MakeMock
2023-06-03T00:44:32.959887Z [scheduler] scheduler thread exit
unknown location:0: 
fatal error: in "psbt_wallet_tests/psbt_updater_test": std::runtime_error: BerkeleyDatabase: Error 22, can't open database 
wallet/test/psbt_wallet_tests.cpp:16: 
last checkpoint: "psbt_updater_test" fixture ctor

I think it is time to make that a high priority issue.

Got it. Thank you for letting me know. Just an FYI, I did berkdb install using brew. Not sure what is your opinion on using berkley-db installation from homebrew, but I got much farther in CI task.

P.S. Tried copy-and-paste CI error here but it comes out in weird fonts so I'll make a full commit instead.

The font is boring, make it comic sans like the rest of the client!

I just saw that Bitcoin Core fixed this by no longer supporting "legacy" bdb based wallets in the macOS arm build on 24.1 / 25.0 - it looks like we're not the only project experiencing issues with native usage of bdb on macOS.

I honestly would still want to find a way to make it work, we do not have the luxury of depreciating bdb. I'll work on a deep analysis of this issue as it affects all versions / branches.

If that is true I find it outrageous. There are a lot of people storing coins in "old" wallets and it's not the job of Bitcoin maintainers to break everything for fun but rather to maintain the software...

Hmm it's only for macOS native builds - cross-compilation with bdb still works, here too. So it's not depreciation of the feature, it is specific to the platform.

I've personally experienced issues with bdb on the macOs native builds since a Monterrey update (a 12.1.x iirc), which happened right after the fix done in #2885.

Note: I think that we can port #3308 to 1.21 to unblock the bdb issues. Will work on that as soon as we've seen some successful testing on the 1.14 solution.

In reworking the fixes for non-linux arm64, I have found that:

• build: bdb detection and configuration fixes for macOs/brew #3308 applies here and can be cherry-picked. After that the CI configuration for MacOS native also becomes simpler than it is now and simpler than is proposed here.
• Boost 1.82 kills some libevent includes that cause breakage on bitcoin_util.so - need to backport bitcoin/bitcoin@058eb69
• Since crc32c is a subtree, we should never edit it, instead I'm preparing a subtree sync from bitcoin-core/crc32c-subtree

I think that to avoid having to deal with a big PR that fixes all these things at once, I instead will propose a plan like:

1. Temporarily disable the macOS native CI
2. PR all the fixes, test them for regression because neither of these will cause CI success on their own
3. Re-enable macOS native CI