aboutsummaryrefslogtreecommitdiff
path: root/depends
AgeCommit message (Collapse)Author
2020-10-29Merge #20195: build: fix mutex detection when building bdb on macOSWladimir J. van der Laan
d0a829e9632379e42f0be5c554e3b692f0d14a95 build: fix mutex detection when building bdb on macOS (fanquake) Pull request description: Starting with the Apple Clang shipped with Xcode 12, [Apple has enabled -Werror=implicit-function-declaration by default](https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes): > Clang now reports an error when you use a function without an explicit declaration when building C or Objective-C code for macOS (-Werror=implicit-function-declaration flag is on). This additional error detection unifies Clang’s behavior for iOS/tvOS and macOS 64-bit targets for this diagnostic. (49917738) This causes bdbs mutex detection to fail when building on macOS (not cross-compiling): ```bash checking for mutexes... UNIX/fcntl configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM. configure: error: Unable to find a mutex implementation ``` as previously emitted warnings are being turned into errors. i.e: ```bash configure:18704: checking for mutexes configure:18815: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -mmacosx-version-min=10.12 --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o conftest -pipe -O2 -I/Users/michael/github/fanquake-bitcoin/depends/x86_64-apple-darwin19.6.0/include -L/Users/michael/github/fanquake-bitcoin/depends/x86_64-apple-darwin19.6.0/lib conftest.c -lpthread >&5 conftest.c:46:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main() { ^ conftest.c:51:2: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration] exit ( ^ conftest.c:51:2: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit' 1 warning and 1 error generated. ``` Append `-Wno-error=implicit-function-declaration` to `cflags` so that `-Wimplicit-function-declaration` [returns to being a warning](https://clang.llvm.org/docs/UsersManual.html#cmdoption-wno-error), and the configure checks succeed. Fixes #19411. ACKs for top commit: laanwj: Code review ACK d0a829e9632379e42f0be5c554e3b692f0d14a95 Tree-SHA512: 7813005b1fc0b370f843b6c0672acab32c999416e92c3f02b75d866e9c7aa41fe5822704fc74de6b65f0d7d94f2cdd05cc7c3ee83295ff1ecbc71d8492b9a2bf
2020-10-27build: fix mutex detection when building bdb on macOSfanquake
Starting with the Clang shipped with Xcode 12, Apple has enabled -Werror=implicit-function-declaration by default. This causes bdbs mutex detection to fail when building on macOS (not cross-compiling): checking for mutexes... UNIX/fcntl configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM. configure: error: Unable to find a mutex implementation as previously emitted warnings are being turned into errors. i.e: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration] Append -Wno-error=implicit-function-declaration to cflags so that -Wimplicit-function-declaration returns to being a warning, and the configure checks will succeed. Fixes #19411.
2020-10-27Merge #19124: doc: Document ALLOW_HOST_PACKAGES dependency optionWladimir J. van der Laan
47e2a35fac9951c125b784a9d14027338c56c750 doc: Document ALLOW_HOST_PACKAGES dependency option (skmcontrib) Pull request description: Provided entry in depends, README.md to ensure that ALLOW_HOST_PACKAGES dependency option is documented, #19113 ACKs for top commit: hebasto: ACK 47e2a35fac9951c125b784a9d14027338c56c750. Tree-SHA512: 10d9285885be25f092881e4886c6a804cd42b5224bdf1dfa8b8369463808ddaf533a8604f14f7fe45478434a22feae98053f4731b51d976c071d69882bdac72b
2020-10-14Add sqlite to travis and dependsAndrew Chow
2020-09-23Merge #19868: build: Fix target nameMarcoFalke
7a89f2e6c539a54bcaa24bff41aae3910244ad3d build: Fix target name (Hennadii Stepanov) Pull request description: It seems like a typo :) This PR: - fixes errors when building a package in depends for `HOST=x86_64-apple-darwin16` (fix #19799) - is a correct alternative to https://github.com/bitcoin/bitcoin/pull/19764/commits/d25e0e308f51f6b995e5d0033224c424dc8afc2c from #19764 ACKs for top commit: icota: tACK https://github.com/bitcoin/bitcoin/pull/19868/commits/7a89f2e6c539a54bcaa24bff41aae3910244ad3d dongcarl: Code Review ACK 7a89f2e6c539a54bcaa24bff41aae3910244ad3d theuni: ACK 7a89f2e6c539a54bcaa24bff41aae3910244ad3d. Tree-SHA512: a0bcbc6805d3450e201476ef1e22e0eb53903db1586c5515314c19afd337bded887e56de0fbe62feaf359b2de15dbccd49a44f1a8b566b4c64f5ae3d94a2ab6d
2020-09-16build: Fix target nameHennadii Stepanov
2020-09-15build: patch qt libpng to fix powerpc buildfanquake
This is an alternative to #19751 that fixes the build without requiring splitting out libpng. This patch can be dropped once we are building qt 5.12.0 or later.
2020-09-02Merge #19685: depends: CMake invocation cleanupfanquake
b8936883573708059357a66f67fad9dc77a8bade depends: Specify LDFLAGS to cmake as well (Carl Dong) b3f541f618fe1f3d44baf6a0dd4299173c81f752 depends: Prepend CPPFLAGS to C{,XX}FLAGS for CMake (Carl Dong) 8e121e550953711cd03d7b6c221afd065c325c5e depends: Cleanup CMake invocation (Carl Dong) 8c7cd0c6d9f295bcb6913e3c69c9dac4ce2b25ce depends: More robust cmake invocation (Carl Dong) 3ecf0eca634601da216b06f091f95456c047f39c depends: Use $($(package)_cmake) instead of cmake (Carl Dong) Pull request description: - Use `$($(package)_cmake)` instead of invoking `cmake` directly - Use well-known env vars instead of overriding CMake variables ACKs for top commit: ryanofsky: Code review ACK b8936883573708059357a66f67fad9dc77a8bade. Only changes since last review are new commits adding whitespace, cppflags and ldflags to cmake invocation Tree-SHA512: cfcd8cc9dcd0b336cf48b82fca9fe4bbc7930ed397cb7a68a07066680eb4c1906a6a9b5bd2589b4b4999e8f16232fa30ee9b376b60f4456d0fff931fbf9cc19a
2020-08-26build: replace wingenminiupnpcstrings sed with a patch in miniupnpc packagefanquake
We should be able to drop this once we are using 2.1 or later. See upstream commit: 9663c55c61408fdcc39a82987d2243f816b22932.
2020-08-26build: replace qtranslations lrelease sed with a patch in qt packagefanquake
2020-08-25build: replace FreeType back-compat sed with a patch in qt packagefanquake
2020-08-25build: replace pwd sed in qt package with a patchfanquake
2020-08-25build: remove no-longer needed qt workaroundfanquake
2020-08-25build: remove no-longer needed qt configure workaroundfanquake
This was fixed upstream in c45595d64831990311f92fcebc4e34e2797f5352.
2020-08-25build: use patch rather than sed in zeromq packagefanquake
2020-08-25build: use patch rather than sed in native_cctools packagefanquake
2020-08-25build: use patch rather than sed in fontconfig packagefanquake
2020-08-25build: use patch rather than sed in Boost packagefanquake
The depends comment is actually incorrect, and this can be dropped once we move to 1.71.0 or later.
2020-08-25build: use patch rather than sed in bdb packagefanquake
2020-08-25Merge #18405: build: Drop all of the ZeroMQ patchesfanquake
f642b49af73fedc6dc9af4ac299e4cfa80755583 build: Drop ZeroMQ patch for glibc < 2.12 (Hennadii Stepanov) 079df9609e6ed2a09949ebe5e98a179f61709801 build: Drop ZeroMQ patch for Mingw-w64 < 4.0 (Hennadii Stepanov) Pull request description: This PR gets rid of the all patches for ZeroMQ: - the [Mingw-w64 5.0 (Ubuntu 18.04 bionic)](https://packages.ubuntu.com/bionic/mingw-w64) is used to build the [Windows](https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md) binaries - it is safe to use `pthread_setname_np` since #17538 when the minimal `glibc` version is set to 2.17; see: https://github.com/bitcoin/bitcoin/pull/11986#issuecomment-366105050 ACKs for top commit: fanquake: ACK f642b49af73fedc6dc9af4ac299e4cfa80755583. Tree-SHA512: a2c97cdb682cd7d96a666ad099f20725a32bf8fda0842fc5534ca08a1634c90ba80afde92f9054595ed2501fbc5c02abbe3da765934ecff12d836ff25e277fc5
2020-08-18depends: Specify LDFLAGS to cmake as wellCarl Dong
2020-08-18depends: Prepend CPPFLAGS to C{,XX}FLAGS for CMakeCarl Dong
This is similar to how we do it for qt.mk.
2020-08-18depends: Cleanup CMake invocationCarl Dong
2020-08-11doc: Document ALLOW_HOST_PACKAGES dependency optionskmcontrib
2020-08-07depends: More robust cmake invocationCarl Dong
Specify well-known env vars instead of using a workaround to split up CC and CXX.
2020-08-07depends: Use $($(package)_cmake) instead of cmakeCarl Dong
2020-07-31[depends] boost: patch unused variable in boost_processSjors Provoost
Co-Authored-By: fanquake <fanquake@gmail.com>
2020-07-29doc: Clang 8 or later is required with FORCE_USE_SYSTEM_CLANGfanquake
The usage of pragmas within the macOS SDK requires LLVM Clang 8. This is the 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 using 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. ```
2020-07-28Merge #19530: depends: build LTO support into Apple's ld64fanquake
5962522fbcb7b72c269fc271ac4463791a103918 depends: bump native_cctools for fixed lto with external clang (Cory Fields) 00d1ba7aaadbe881995ac1497633a012bc487bdd depends: enable lto support for Apple's ld64 (Cory Fields) Pull request description: This didn't work for a few reasons (various toolchain compatibility issues) the last time I tested it, but after the last round of bumps it works with no apparent issues. Note that this does not _enable_ LTO by default in any way, only hooks up the machinery for ```-flto``` to work correctly when specified. Lines were split for an easier rebase after #17919 is merged. ACKs for top commit: fanquake: ACK 5962522fbcb7b72c269fc271ac4463791a103918. The relevant option upstream is [here](https://github.com/tpoechtrager/cctools-port/blob/master/cctools/m4/llvm.m4#L4). Tree-SHA512: df2775e74e7bc847e6cef94cb8457d503d6c9e2fdea861e51386fa6ed5a7ba688241db3685561ae1a32f66724c1b3801727252025f00c04b90a3bdc8a4f6f93b
2020-07-22Merge #19553: build: pass -fcommon when building genisoimageWladimir J. van der Laan
2a701a1c42c37e48aae70156692aa08aaae11088 build: pass -fcommon when building genisoimage (fanquake) Pull request description: Starting with the 10.1 release, GCC [defaults to -fno-common](https://gcc.gnu.org/gcc-10/porting_to.html). This causes linking issues when building genisoimage: ```bash [ 98%] Building C object genisoimage/CMakeFiles/genisoimage.dir/checksum.o [100%] Linking C executable genisoimage /usr/bin/ld: CMakeFiles/genisoimage.dir/apple.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here /usr/bin/ld: CMakeFiles/genisoimage.dir/boot.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here /usr/bin/ld: CMakeFiles/genisoimage.dir/desktop.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here /usr/bin/ld: CMakeFiles/genisoimage.dir/dvd_file.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here ``` Rather than patching genisoimage further, just pass -fcommon to preserve the legacy GCC behaviour. Noticed [while testing #19530](https://github.com/bitcoin/bitcoin/pull/19530#issuecomment-659802512). ACKs for top commit: laanwj: ACK 2a701a1c42c37e48aae70156692aa08aaae11088 hebasto: ACK 2a701a1c42c37e48aae70156692aa08aaae11088, tested on Fedora 32 (x86_64, GCC 10.1.1): Tree-SHA512: 0e6dd1b4c7c3f5b6997616da27a7ea54f757c81677766ee6813c776356527787a32b959f834e699fee9798553b13bcb142469f442c5e7a04f810f2c06e3a9505
2020-07-19build: pass -fcommon when building genisoimagefanquake
Starting with the 10.1 release, GCC defaults to -fno-common. This causes linking issues when building genisoimage: ```bash [ 98%] Building C object genisoimage/CMakeFiles/genisoimage.dir/checksum.o [100%] Linking C executable genisoimage /usr/bin/ld: CMakeFiles/genisoimage.dir/apple.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here /usr/bin/ld: CMakeFiles/genisoimage.dir/boot.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here /usr/bin/ld: CMakeFiles/genisoimage.dir/desktop.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here /usr/bin/ld: CMakeFiles/genisoimage.dir/dvd_file.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here ``` Rather than patching genisoimage further, pass -fcommon to preserve the legacy GCC behaviour.
2020-07-18doc: Update macOS cross compilation dependencies for FocalHennadii Stepanov
2020-07-17Merge #19536: qt, build: Fix QFileDialog for static buildsfanquake
6457361e90c0cf704d086c51d75f51dbdfd374d7 qt: Fix QFileDialog for static builds (Hennadii Stepanov) Pull request description: This change partially reverts 248e22bbc0d7bc40ae3584d53a18507c46b0e553 (#16386) and makes `QFileDialog`s work again for static builds. Fixes https://github.com/bitcoin-core/gui/issues/32. ACKs for top commit: fanquake: ACK 6457361e90c0cf704d086c51d75f51dbdfd374d7. Although it would be good to know exactly _why_ this fixes the issue. At this stage I also don't think this should be a blocker for 0.20.1. theuni: ACK 6457361e90c0cf704d086c51d75f51dbdfd374d7 Tree-SHA512: 8ad27e0bcae6debd02f73b7c374743e37d4edd806922b103a2fe494cf2d9930fe9ef3107b5a6c61f3c466cf7462de2641171880398954e7f2c4f417f5bb820d7
2020-07-16depends: bump native_cctools for fixed lto with external clangCory Fields
https://github.com/tpoechtrager/cctools-port/pull/85 was merged upstream, which fixes lto detection for external clang with some Linux Distro's including Ubuntu.
2020-07-16depends: enable lto support for Apple's ld64Cory Fields
Note that this does not _enable_ lto by default in any way, only hooks up the machinery for -flto to work correctly. enable-lto-support is explicitly used for pinned-clang because we know it works. It is neither enabled nor disabled in the external clang case so that it can be auto-detected.
2020-07-16qt: Fix QFileDialog for static buildsHennadii Stepanov
This change partially reverts 248e22bbc0d7bc40ae3584d53a18507c46b0e553.
2020-07-10depends: Add documentation for FORCE_USE_SYSTEM_CLANG make flagCarl Dong
2020-07-10depends: Reformat make options as definition listCarl Dong
2020-07-10depends: Add justifications for macOS clang flagsCarl Dong
2020-07-10depends: specify libc++ header location for darwinCory Fields
For depends builds this was fixed by fbcfcf69, which deleted the conflicting headers. When we no longer control the clang installation, we need to ensure that the SDK's libc++ headers are used rather than the ones shipped with clang. We can do that by turning off the default include path and hard-coding our own. This hard-coded path is ok because we control (via SDK packaging) where these headers end-up. Side-note: Now that this path is hard-coded in depends, we can potentially package the SDK differently, as the c++ folder can live wherever is most convenient for us.
2020-07-10depends: force a new host id string if FORCE_USE_SYSTEM_CLANG is in useCory Fields
This should be caught by the differing clang --version outputs, but because we haven't yet extracted our pinned clang, the system one is actually used for the version check. That's not a problem because bumping our pinned clang will cause a rebuild of everything anyway.
2020-07-07depends: Allow building with system clangCarl Dong
2020-07-07depends: Decouple toolchain + binutilsCarl Dong
For now they remain the same, but in the next commit, we will assign them differently according to wether or not we're using system clang.
2020-07-03Merge #19407: doc: explain why passing -mlinker-version is required when ↵fanquake
cross-compiling a8d39b88406e2047746366355666b5f603105a2e doc: explain why passing -mlinker-version is required (fanquake) Pull request description: I have been down a 🐇 hole. Closes #19359. When Clang is compiled, [a check is run](https://github.com/llvm/llvm-project/blob/release/8.x/clang/CMakeLists.txt#L353) to define `HOST_LINK_VERSION` as the output of `$CMAKE_LINKER -v`. Note the this is the version of the linker being used to compile Clang itself.. and this check is only run when compiling Clang for macOS. In the Clang driver, if `HOST_LINK_VERSION` has been defined, there is some additional runtime functionality. An `-mlinker-version` argument, with the value of `HOST_LINK_VERSION` [will be added to the linker arguments](https://github.com/llvm/llvm-project/blob/89de0d8dfbb9a6ff1f8b141ed70b563ecc094878/clang/lib/Driver/Driver.cpp#L382), if `-mlinker-version` has not been passed in by the user. This is a bit weird, as by default, you are setting `-mlinker-version` to the version of the linker that was used to build the Clang binary, not the linker which will be used when compiling. The commit which introduced the functionality, https://github.com/llvm/llvm-project/commit/628fcf4e3b79ba9f41dd1b49b1aba7a20b68fc0e, described it as a "hack", that should be replaced. However, that was 10 years ago, and the behaviour is still here. In the Darwin driver, [a check is done](https://github.com/llvm/llvm-project/blob/89de0d8dfbb9a6ff1f8b141ed70b563ecc094878/clang/lib/Driver/ToolChains/Darwin.cpp#L208) for the `-mlinker-version` argument. If there is no argument, the version will default to `0`. Given the above, this should never happen when using Clang for macOS. A series of comparisons are then performed, to check whether the linker version is modern enough to enable certain features, like [`-demangle`](https://github.com/llvm/llvm-project/blob/89de0d8dfbb9a6ff1f8b141ed70b563ecc094878/clang/lib/Driver/ToolChains/Darwin.cpp#L215). ### What this means #### macOS A Clang compiled for macOS, i.e `clang+llvm-8.0.0-x86_64-apple-darwin`, will have `HOST_LINKER_VERSION` set to the version of the linker used to compile Clang itself. At runtime, `-mlinker-version=HOST_LINKER_VERSION` will be added to the linker args, if `-mlinker-version` wasn't passed in. In the Darwin driver, additional arguments, like `-demangle`, will be added to the linker arguments, because `HOST_LINKER_VERSION` was likely some very modern version of `lld` or `ld64`. #### Linux (cross compilation in depends) A Clang compiled for Linux, i.e `clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-14.04`, which we now use for macOS builds in depends, will behave differently. As it's built for Linux, `HOST_LINKER_VERSION` was not defined at compile time, and there will be no default behaviour of appending `-mlinker-version=HOST_LINKER_VERSION` to the linker args. Thus, unless you pass in `-mlinker-version` yourself, when the version checks are done in the Darwin driver, no modern linker features will be enabled, as the version will have defaulted to `0`. Therefore, it's important that we continue to pass `-mlinker-version="our LD64 version"` as part of our compilation flags, if we want to have "modern" linker features enabled for our macOS builds. #### Summary [Clang 8](https://releases.llvm.org/download.html#8.0.0). Building a macOS binary. Link line with path arguments trimmed. | | default behaviour | `-mlinker-version=100` (`-demangle threshold`) | `-mlinker-version=530` | | - | --------------- | --------------------- | ---------------------- | | macOS Clang | `-demangle -lto_library ../libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.15.0 -o a.out ../test-b8b9b3.o -lc++ -lSystem ../libclang_rt.osx.a` | `-demangle -dynamic -arch x86_64 -macosx_version_min 10.15.0 -o a.out ../test-a66966.o -lc++ -lSystem ../libclang_rt.osx.a` | same as default | | Linux Clang | `-dynamic -arch x86_64 -macosx_version_min 10.12.0 -o a.out ../test-bfce57.o -lc++ -lSystem` | `-demangle -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o a.out ../test-a846a3.o -lc++ -lSystem` | `-demangle -lto_library ../libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o a.out ../test-de0280.o -lc++ -lSystem` | Note: Most links here are pointing to the 8.x branch of LLVM/Clang, as we are using that version in depends. Note: To add a little more confusion, you wont see `-mlinker-version X` in your compile flags, you'll see [`-target-linker-version X`](https://github.com/llvm/llvm-project/blob/431daedee4dcce0c096c400dbf8e64dfe7254fb6/clang/lib/Driver/ToolChains/Clang.cpp#L4777). ACKs for top commit: laanwj: ACK a8d39b88406e2047746366355666b5f603105a2e Tree-SHA512: 92f93079a5e59a0d561e74336b5cb03e3bf5a34437f5850283b9128c7624494b8285ec16290b1fa8103fe87f8789a53ce44b17902b8c1db5fde24d74b76fb168
2020-06-30build: pass _WIN32_WINNT=0x0601 when building libevent for Windowsfanquake
This enables of the use of AI_* definitions in the Windows headers, specifically AI_ADDRCONFIG, which fixes an issue with libevent and ipv6 on Windows. It also aligns with what we define in configure when building Core.
2020-06-29doc: explain why passing -mlinker-version is requiredfanquake
2020-06-25depends: Patch libevent build to fix IPv6 -rpcbind on WindowsLuke Dashjr
libevent uses getaddrinfo when available, and falls back to gethostbyname Windows has both, but gethostbyname only supports IPv4 libevent fails to detect Windows's getaddrinfo due to not including the right headers This patches libevent's configure script to check it correctly
2020-06-22darwin: pass mlinker-version so that clang enables new featuresCory Fields
Without this clang fails to add any newly-added linker features. Removing this in ca5055a5aa07aba81a87cf12f6f0526a63c423b5 was likely a regression. See https://github.com/bitcoin/bitcoin/pull/19240#issuecomment-647764049 for more discussion.
2020-06-22macos: Bump to xcode 11.3.1 and 10.15 SDKCory Fields
This gets us a newer SDK with c++17 support and retains 10.12 back-compat. Co-authored-by: Carl Dong <contact@carldong.me>
2020-06-22depends: bump MacOS toolchainCory Fields
clang 6.0.1 -> 8.0.0 cctools 921 -> 949.0.1 ld64 409.12 -> 530
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-03 00:44:39 +0000