Hennadii Stepanov

> The build is currently failing for Qt, something to follow up with: > > ```shell > 1 warning generated. > x86_64-apple-darwin-ranlib: error: Invalid option: '-no_warning_for_no_symbols' > make[4]: *** [Makefile:436:...

I'm still wondering why does the Qt build system recognize llvm's clang as Apple's clang: ``` $ make -C depends qt_configured HOST=x86_64-apple-darwin ... Configure summary: Building on: linux-g++ (x86_64, CPU...

> However note that `bitcoin-qt` still isn't being built because of duplicate symbol issues when running our configure checks. ``` x86_64-apple-darwin-ld: error: duplicate symbol: __Z10lcQpaFontsv >>> defined in /home/hebasto/GitHub/bitcoin/depends/x86_64-apple-darwin/lib/libQt5ThemeSupport.a(qgenericunixthemes.o) >>>...

Bump to https://github.com/llvm/llvm-project/tree/llvmorg-14.0.0?

Tested 46d8f32086d89de919036613b8cb437bc71a9286 on Ubuntu 22.04. The f41493b9023acb6f3c237f6609f34f99d7e52dc1 commit introduced an error on my system: ``` $ make -C depends HOST=x86_64-apple-darwin boost FORCE_USE_SYSTEM_CLANG=1 ... Preprocessing boost... Configuring boost... tar: option requires...

@theuni > Another one for me: my mingw32 build with ctests fails due to missing valgrind: > > ```shell > Valgrind .............................. OFF > ... > ctime_tests ......................... ON >...

> But on my win32 build with no valid runtime (valgrind/msan/whatever) I believe cmake should throw an error telling me "SECP256K1_BUILD_CTIME_TESTS can't be set without valgrind/msan". Sounds like a nice...

The current Autotools-based build system provides a user with an option to override compiler flags using the `CFLAGS` variable. That is not the case in the new CMake-based build system...

> - [ ] Set `-fvisibility-inlines-hidden`? (https://github.com/bitcoin-core/secp256k1/pull/1113#discussion_r1124273356) GCC: ``` cc1: warning: command-line option ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C ``` So removing this task from the list.

During reviewing of #1113, there was a [suggestion](https://github.com/bitcoin-core/secp256k1/pull/1113#issuecomment-1179172504): > And expressing `Coverage` as build type in CMake seems to use build types in the right way. Later, https://github.com/bitcoin-core/secp256k1/pull/1188 introduced a...