e60ef21b8a0f62ebc2e0bdbb5943fa80cc4d98b2 doc: Clang 8 or later is required with FORCE_USE_SYSTEM_CLANG (fanquake)
Pull request description:
The usage of pragmas within the macOS SDK requires LLVM Clang 8. This is
the same version as our prebuilt Clang, however the minimum is worth noting
here as they may diverge and/or expert users might expect they could use an
earlier version.
If you compile depends using `FORCE_USE_SYSTEM_CLANG=1` and Clang 7 you'll see output like:
```bash
In file included from kernel/qcore_mac_objc.mm:44:
In file included from /bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSText.h:9:
In file included from /bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:19:
In file included from /bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSResponder.h:10:
/bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:19:1: error:
expected 'push' or 'pop' after '#pragma clang attribute'
/bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/usr/include/os/availability.h:104:273: note: expanded from macro
'API_UNAVAILABLE_BEGIN'
...__API_UNAVAILABLE_BEGIN5, __API_UNAVAILABLE_BEGIN4, __API_UNAVAILABLE_BEGIN3, __API_UNAVAILABLE_BEGIN2, __API_UNAVAILABLE_BEGIN1, 0)(__VA_A...
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
```
I've got a [godbolt here](https://godbolt.org/z/j6r987) that contains a demo of the issue (based off the macOS SDK). It will compile with Clang 8 but not with Clang 7.
ACKs for top commit:
laanwj:
ACK e60ef21b8a0f62ebc2e0bdbb5943fa80cc4d98b2
Tree-SHA512: affc082a4b28d9cd102a844e10f63f55f0f20a9f840e5d8037a41470ad1ea83edc3075ce262b1d618c59c9b75445e52ddd9ba9f84c5ac3da9ce20681473c47b1
fa193dc8e6f3b96fa2dba2f1c1668f7720fed320 doc: Remove win32 from the release process (MarcoFalke)
faf666f8148eeb305a9c4f78459aff2c7268016b Remove Windows 32 bit build (MarcoFalke)
Pull request description:
The Windows 32 bit build has been removed from https://bitcoincore.org/en/download/, so unless there are complaints, we don't need to build it even
ACKs for commit fa193d:
fanquake:
utACK fa193dc8e6
Tree-SHA512: d6f2976a2e0c407698f720b00ac23ec4056626de4eff8621f4c5581120af0460afd1bdef72329cc0e7d92afca48d94ae5fce6777cb36bfabb60b8034ff08fd88
989c8990bb765eef45c8ee471f084ca81a0bead4 Rename “OS X” to the newer “macOS” convention (Giulio Lombardo)
Pull request description:
Since 2016, with [macOS 10.12 Sierra](https://en.wikipedia.org/wiki/MacOS_Sierra), Mac OS X has been renamed in macOS. It would be a nice if Bitcoin's macOS build instructions follow this naming convention to avoid misunderstandings.
Tree-SHA512: 51b7d54bfc39a1a9d0773c64780817c7beca7094aded80481086287474dfa272bf0a1dfa6ef6e3cae91548aa127f65fa730003dddcb97147cdc8c249146aea22
* build: Add cmake as depends package (cmake.mk)
The bls-signatures library requires cmake 3.14
* depends: Update chia_bls to version 1.0.0 of dashpay/bls-signatures
* depends: Rename package chia_bls to bls-dash
* depends: Disable blspy/tests/benchmarks build for chia_bls
Note: Building with tests would require the following:
depends: Fix macOS build for versions < 10.12
Seems like older versions of macOS pretend to support c++17 std libs but do not have/have issues with uncaught_exceptions. "Catch", the testing framework used in the bls lib wants those by default but setting `DCATCH_CONFIG_NO_CPP17_UNCAUGHT_EXCEPTIONS` disables them which should be just fine to do in all cases here.
---
depends/packages/chia_bls.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/depends/packages/chia_bls.mk b/depends/packages/chia_bls.mk
index e79a85844f..25749b74ab 100644
--- a/depends/packages/chia_bls.mk
+++ b/depends/packages/chia_bls.mk
@@ -28,6 +28,8 @@ define $(package)_set_vars
$(package)_config_opts_darwin+= -DCMAKE_AR="$(host_prefix)/native/bin/$($(package)_ar)"
$(package)_config_opts_darwin+= -DCMAKE_RANLIB="$(host_prefix)/native/bin/$($(package)_ranlib)"
endif
+
+ $(package)_cppflags+= -DCATCH_CONFIG_NO_CPP17_UNCAUGHT_EXCEPTIONS
endef
define $(package)_config_cmds
--
* depends: Drop obsolete variable
* bls: Integrate the upgraded version into the codebase
* depends: Pre-fetch relic to fix gitian
Can fetch apt packages only when building with lxc
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
3828a79711 scripted-diff: prefer MAC_OSX over __APPLE__ (fanquake)
fa6e841e89 gui: remove macOS ProgressBar workaround (fanquake)
68c272527f gui: remove SubstituteFonts (fanquake)
6c6dbd8af5 doc: mention that macOS 10.10 is now required (fanquake)
84b0cfa8b6 release: bump minimum required macOS to 10.10 (fanquake)
26b15df99d depends: set OSX_MIN_VERSION to 10.10 (fanquake)
Pull request description:
Closes#13362
d99abfddb0c8f2111340a6127e77cc686e0043d8
This workaround should no longer be required, as it should have only been in use when compiled with the 10.7 SDK, which we haven't been building with for a while now.
5bc5ae30982a0f0f6a9804b05d99434af770c724
The bugreport linked with this code is for an unrelated? issue, however from what I can tell the correct QTBUG is this one https://bugreports.qt.io/browse/QTBUG-20880. Reading though the discussion there, it seems that the way progress bars are animated changed in macOS 10.10.
Qt was patched [here (5.5+)](https://codereview.qt-project.org/#/c/112379/):
> Disable progress bar animations on 10.10 Yosemite and higher - the native style does not animate them any more. Keep the indeterminate progress bar animation.
Given all of that, I don't think this is worth keeping around, as it would seem to only be useful in the case that a macOS user is compiling with a Qt < 5.5. That should be pretty unlikely, as we don't support downloaded Qt binaries, and brew currently provides [5.11.1](571b46213c/Formula/qt.rb).
Tree-SHA512: 4278cb30cc9bcb313e166129ecf032c808995f8b51a3123637c47860a0010ac88f86f82ec44792153b6b1e5cca595f25013b2eaeae80194647b9ce4f7eaf32c1
974f0bf8e684696be7796dbf3d48ff0a41f4ac26 depends: Mention RISC-V known compilation issue with gcc-7.3.x (Wladimir J. van der Laan)
0d1f38c45ff40f17b42074e3b58211e794a19edb depends: update zmq config.guess/config.sub for riscv support (fanquake)
409481c46555afb34a038dbc69a8285b83eb952e depends: latest config.sub (fanquake)
d7005e9988ddae4d3507963b42c525257c34ddb0 depends: latest config.guess (fanquake)
359e2e352590e1e473da70e28a38d14a068a3103 depends: Add RISC-V support (Wladimir J. van der Laan)
Pull request description:
This adds support for riscv32 and riscv64 builds to the depends system.
The change consists of documentation and build system changes. The most significant change is an update of `config.sub` and `config.guess` inside zeromq patch, as the current version does not recognize the `riscv*` host tuples (there's no new version of ZeroMQ yet with newer ones).
Good thing: RISC-V 64-bit toolchain packages can be installed out of the box on Ubuntu 18.04+.
I would also like to add RISC-V 64-bit executables to gitian, but this will not be possible until #12511 .
Tree-SHA512: 358ed72ee9e4ae44e7d305c09a4ff5ce5460eeb7ed915eb25d39c8f43b61e7b347f51bf0ae5d83ddb4ce8876dea7703c926b3baa3cccb4932b3bc17160d801bb
(cherry picked from commit 6c6a3001e51b1679af2f375f158d8c87bbb330bc)
# Conflicts:
# depends/Makefile
31a013563 Add required package dependencies for depends cross compilation [skip-ci] (Jonas Schnelli)
Pull request description:
Stumbled over this during a setup of a new depends compile system.
Related to #8913.
Tree-SHA512: 67e2fdf9ca3cbedeb02982fa73771dd36978b319e9291ea5a41ede7fdf772c4505ccc9523b48fe66ead927f141efefbdf1e3eaa19a9d8a1304861a8ede040056
Documentation more readable when viewed on Github.
Some extra changes by @laanwj:
- Make README.usage the default README. This is more convenient from a
user perspective. Link to other documentation in this default README
- Add list of popular targets for cross compilation, change default to
Win64 instead of Win32
