aboutsummaryrefslogtreecommitdiff
path: root/depends
AgeCommit message (Collapse)Author
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-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
2020-06-22native_cctools: Don't use libc++ from pinned clangCarl Dong
Now that we include the macOS SDK libc++ headers in our macOS SDK tarball, we no longer need this hack to use the libc++ from our pinned clang.
2020-06-22Adapt rest of tooling to new SDK naming schemeCarl Dong
2020-06-13Merge #18297: build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hosts ↵fanquake
including Windows 8a26848c460160e1279f26bc413f693a34e33b9d build: Fix m4 escaping (Hennadii Stepanov) 9123ec15db104397998f5084afc69403d2f9e4b8 build: Remove extra tokens warning (Hennadii Stepanov) fded4f48c33742d7c790335c8de59c15b80d94e6 build: Remove duplicated QT_STATICPLUGIN define (Hennadii Stepanov) 05a93d5d96101b45d87571af5b772c7a1e82fd27 build: Fix indentation in bitcoin_qt.m4 (Hennadii Stepanov) ddbb41931019ed4226af3df37874c7eb7cf570f1 build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hosts (Hennadii Stepanov) 492971de35bab26346545f68365872211f458b00 build: Fix mingw pkgconfig file and dependency naming (Hennadii Stepanov) Pull request description: This PR makes `bitcoin_qt.m4` to use `pkg-config` for all hosts and removes non-pkg-config paths from it. This is a step towards the idea which was clear [stated](https://github.com/bitcoin/bitcoin/pull/8314#issue-76644643) by Cory Fields: > I believe the consensus is to treat Windows like the others and require pkg-config across the board. We can drop all of the non-pkg-config paths, and simply AC_REQUIRE(PKG_PROG_PKG_CONFIG) There are two unsolved problems with this PR. If depends is built with `DEBUG=1` the `configure` script fails to pickup Qt: - for macOS host (similar to, but not the same as #16391) - for Windows host (regression) The fix is ~on its way~ submitted in #18298 (as a followup). Also this PR picks some small improvements from #17820. ACKs for top commit: theuni: Code review ACK 8a26848c460160e1279f26bc413f693a34e33b9d dongcarl: Code Review ACK 8a26848c460160e1279f26bc413f693a34e33b9d laanwj: Code review ACK 8a26848c460160e1279f26bc413f693a34e33b9d Tree-SHA512: 3b25990934b939121983df7707997b31d61063b1207d909f539d69494c7cb85212f353092956d09ecffebb9fef28b869914dd1216a596d102fcb9744bb5487f7
2020-05-30Merge #18820: build: Propagate well-known vars into dependsfanquake
f0d7ed10b48a6303d8b0cb6f2fc6b8652945bffb depends: Propagate only specific CLI variables to sub-makes (Carl Dong) 0a33803f1c42c938cc7c6c5291ef1f9a1dfb491b depends: boost: Use clang toolset if clang in CXX (Carl Dong) 1ce74bcde341bbab538937544a0e4b4abccdc050 depends: boost: Split target-os from toolset (Carl Dong) 2d4e48081382a58033ed5c3734a4ad810b56a963 depends: boost: Specify toolset to bootstrap.sh (Carl Dong) 3d6603e340d6d461832f0aa204b04343d34af3d4 depends: Propagate well-known vars into depends (Carl Dong) Pull request description: From: https://github.com/bitcoin/bitcoin/pull/18308#issuecomment-598301117 The following monstrosity is quite useful when invoked inside `depends`, and reviewers can use it to compare the behaviour of this change against master. ```bash make print-{{,{host,{,{i686,x86_64,riscv64}_}linux}_}{CC,CXX},boost_{cc,cxx}} ``` It would also be helpful to make sure that setting `HOST`, `CC`, and `CXX` does the right thing. The 3 hosts I found offered good coverage were: `{x86_64,i686,riscv64}-linux-gnu`. As we special-case the `x86_64` and `i686` hosts in `depends/hosts/linux.mk`, and `riscv64` is a sanity check for a non-special-cased host. ACKs for top commit: hebasto: ACK f0d7ed10b48a6303d8b0cb6f2fc6b8652945bffb, tested on Linux Mint 19.3 (x86_64): practicalswift: ACK f0d7ed10b48a6303d8b0cb6f2fc6b8652945bffb -- patch looks correct laanwj: Code review and concept ACK f0d7ed10b48a6303d8b0cb6f2fc6b8652945bffb ryanofsky: Code review ACK f0d7ed10b48a6303d8b0cb6f2fc6b8652945bffb. Changes since last review: adding comment explaining check for predefined make variables, dropping freetype commit, adding commit whitelisting overrides for recursive makes Tree-SHA512: b6b8e76f713c26a0add6cd685824e2f5639109236ee9f89338f7c79cb1b1f2c3897bfb62b80b023d6d1943b5a6eb282a2f827f1f499c5e556eca015d6635fa65
2020-05-27depends: Propagate only specific CLI variables to sub-makesCarl Dong
We want to supply well-known vars to ./configure scripts to do with as they please. However, we do _not_ want to override these well-known vars at make-time as certain build systems expect a self-mangled version of these well-known vars. For example, freetype and bdb will prepend `libtool --mode=compile' to CC and CXX, which, if we override CC on the command line at make-time, will break the build.
2020-05-27depends: boost: Use clang toolset if clang in CXXCarl Dong
2020-05-27depends: boost: Split target-os from toolsetCarl Dong
Previously, we specified the target-os in the toolset (and sometimes used the wrong command line flags), now we have a clear separation, which is favored by ./bootstrap.sh and ./b2. This means that all supported OSes will specify the correct target-os= and toolset= on the command line.
2020-05-27depends: boost: Specify toolset to bootstrap.shCarl Dong
b2 will pickup our user-config.jam just fine, however, bootstrap.sh has its own toolset autodetect mechanism, which doesn't GAF about our user-config.jam
2020-05-27depends: Propagate well-known vars into dependsCarl Dong
For example, doing: make CC=clang CXX=clang++ Should now propagate these settings down to depends packages
2020-05-23gui: update Qt base translations for macOS releasefanquake
These haven't been updated since their addition, so this updates the list that controls which qt base translations are bundled with the macOS binary, to all the languages that are available with qt 5.9.8. This could probably be improved in some way, however qt updates are infrequent, and I didn't want to spend any more time looking at this. Also given that no-one seems to have noticed and/or reported this it wouldn't seem high-priority. Could be backported to 0.20.1.
2020-05-12depends: add MULTIPROCESS depends optionRussell Yanofsky
Builds required packages and passes --enable-multiprocess option to bitcoin build
2020-04-22depends: Add --sysroot option to mac os native compile flagsRussell Yanofsky
Catalina SDK clang stopped automatically searching the SDK include paths when invoked without --sysroot: https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-594600985 https://github.com/Homebrew/homebrew-core/issues/45061 This hasn't been a problem for current native depends packages because are passing their own --sysroot values, and hasn't been a problem for current host packages because they use `darwin_` commands instead of `build_darwin_` commands. But the current `build_darwin_CC` and `build_darwin_CXX` commands are still unnecessarily fragile, and incompatible with new native depends packages added in https://github.com/bitcoin/bitcoin/pull/18677. Cory Fields <cory-nospam-@coryfields.com> suggested in https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-595393546 switching compiler from SDK clang to native clang (from $PATH) to avoid this problem. This is easy and makes a certain amount of sense for building native packages, as opposed to host packages. But fanquake <fanquake@gmail.com> pointed out in https://github.com/bitcoin/bitcoin/pull/18677#discussion_r409934309 that it would be inconsistent use switch to non-SDK compilers while still using other SDK tools like ranlib and install_name_tool. So simplest, minimal fix seems to be just adding the missing --sysroot option.
2020-04-10Revert "Merge #16367: Multiprocess build support"MarcoFalke
This reverts the changes made in merge commit 1b307613604883daea4913a65da30ae073c9dc4d: This reverts commit b919efadff3d0393f4a8c3c1dc735f7ac5c665bb. This reverts commit d54f64c6c700be0604190f52c84fc5f1cdd9f02f. This reverts commit 787f40668dc15980c3d6de028d7950c08175d84a. This reverts commit d6306466626635e6fee44385e6a688c8dc118eb5. This reverts commit e6e44eedd56ecaf59f3fabf8e07ab7dee0ddb1b6.
2020-04-05depends: Use default macos clang compilerRussell Yanofsky
Suggested by Cory Fields <cory-nospam-@coryfields.com> https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-595393546 as alternate workaround for problem described https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-594600985
2020-04-05libmultiprocess depends buildRussell Yanofsky
generated by cgit v1.2.3 (git 2.26.2) at 2024-07-19 11:50:27 +0000