aboutsummaryrefslogtreecommitdiff
path: root/depends
AgeCommit message (Collapse)Author
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
2020-04-03test: remove rapidcheck integration and testsfanquake
2020-03-16build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hostsHennadii Stepanov
This change adds to the BITCOIN_QT_CONFIGURE script ability to use pkg-config for MinGW. All of the non-pkg-config paths are removed as needless. If depends is built with DEBUG=1 the configure script fails to pickup Qt: - for macOS host (similar, but not the same as issue 16391) - for Windows host (regression)
2020-03-09build: Fix mingw pkgconfig file and dependency namingHennadii Stepanov
This change adds the correct suffix to debug mode .pc filenames for MinGW and also to the Qt libraries listed in the `Requires` field. The filename adjustment fixes the accidental overwriting of release mode .pc files with the debug mode variant which required the wrong variant of the libraries when `debug_and_release` is active. Note that macOS also supports the `debug_and_release' configuration but may use the regular library names together with DYLD_IMAGE_SUFFIX. Creation of *_debug.pc files is turned off as they're identical to their non-debug counterparts. More info: - QTBUG-4155 - Qt commit a0d8fb4ac3cb7bafdb39f340055eacee4f957513
2020-03-07build: remove chrono package from depends Boostfanquake
2020-02-12Merge #18004: build: don't embed a build-id when building libdmg-hfsplusfanquake
cb9e88e73a042ff4e1c83289a6f8fa1db03fb093 build: don't embed a build-id when building libdmg-hfsplus (fanquake) Pull request description: There was a [reproducibility issue (IRC logs)](http://www.erisian.com.au/bitcoin-core-dev/log-2020-01-25.html) with the osx `0.19.1rc1` gitian builds. The `build-id` embedded into the `dmg` tool was mismatching. It's possible that differing versions of binutils/ld were the cause. While it was resolved after rebuilding the base gitian image, whether an upstream package issue or fluke, we can remove the possibility of it happening in future by just not embedding a build-id into the `dmg` tool at all. Can close if it's not deemed worth it. You can test this change using the following: ```bash # build libdmg make native_libdmg-hfsplus_built -C depends/ HOST=x86_64-apple-darwin16 -j6 V=1 # master readelf --string-dump .note.gnu.build-id /bitcoin/depends/work/build/x86_64-apple-darwin16/native_libdmg-hfsplus/7ac55ec64c96f7800d9818ce64c79670e7f02b67-3830944ef98/build/dmg/dmg String dump of section '.note.gnu.build-id': [ c] GNU [ 11] CjRa?]?^V8?v?;%n?? # this pr readelf --string-dump .note.gnu.build-id /bitcoin/depends/work/build/x86_64-apple-darwin16/native_libdmg-hfsplus/7ac55ec64c96f7800d9818ce64c79670e7f02b67-a72f53ab110/build/dmg/dmg readelf: Warning: Section '.note.gnu.build-id' was not dumped because it does not exist! ``` ACKs for top commit: laanwj: tested ACK cb9e88e73a042ff4e1c83289a6f8fa1db03fb093 Tree-SHA512: 191eed32ed0a04a908f9c1b22188180b2db2f35bae0281940f0f9da2450c5c6807cd6ff5bbcce7c933a9133387b127c3478f7a39a2918c14f17be19fd9ea19b4
2020-02-11Merge #18104: build: Skip i686 build by default in guix and gitianfanquake
fae9084ac5b10f94bdee54853d307838c4254e9c build: Skip i686 build by default in guix and gitian (MarcoFalke) fa55a2554c2661b8f2a759044d5ac85c9979d9ca depends: Remove reference to win32 (MarcoFalke) Pull request description: Closes #17504 Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default. i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`. ACKs for top commit: practicalswift: ACK fae9084ac5b10f94bdee54853d307838c4254e9c -- patch looks correct dongcarl: ACK fae9084ac5b10f94bdee54853d307838c4254e9c patch looks correct laanwj: Code review ACK fae9084ac5b10f94bdee54853d307838c4254e9c hebasto: ACK fae9084ac5b10f94bdee54853d307838c4254e9c, I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
2020-02-10Merge #18051: build: Fix behavior when ALLOW_HOST_PACKAGES unsetWladimir J. van der Laan
0e519fe28425b0148fe0d026bd084ecd244f5669 build: Fix behavior when ALLOW_HOST_PACKAGES unset (Hennadii Stepanov) Pull request description: On master (f05c1ac444e0c893516535bfdf07c5c8cd9bce16) during building with depends host packages are always considered by `pkg-config` regardless of `ALLOW_HOST_PACKAGES` environment variable. This causes issues like #18042. This is an alternative to #18042 and #18045. On master: ``` $ make HOST=x86_64-apple-darwin16 -C depends $ CONFIG_SITE=$PWD/depends/x86_64-apple-darwin16/share/config.site ./configure ... checking for QT_DBUS... yes ... checking whether to build GUI with support for D-Bus... yes ... ``` --- With this PR: 1) `ALLOW_HOST_PACKAGES` unset ``` $ make HOST=x86_64-apple-darwin16 -C depends $ CONFIG_SITE=$PWD/depends/x86_64-apple-darwin16/share/config.site ./configure ... checking for QT_DBUS... no ... checking whether to build GUI with support for D-Bus... no ... ``` 2) `ALLOW_HOST_PACKAGES=1` ``` $ make HOST=x86_64-apple-darwin16 ALLOW_HOST_PACKAGES=1 -C depends $ CONFIG_SITE=$PWD/depends/x86_64-apple-darwin16/share/config.site ./configure ... checking for QT_DBUS... yes ... checking whether to build GUI with support for D-Bus... yes ... ``` ACKs for top commit: jonasschnelli: Tested ACK 0e519fe28425b0148fe0d026bd084ecd244f5669 - After this PR (and after a `make clean` & `make HOST=x86_64-apple-darwin16` in depends), the macOS depends build on a Debian machine with qt as host package worked (it fails on master due to `ENABLE_DBUS=1`). Tree-SHA512: d11e1c2bc8ce8a07f3f9b465b01c9b2c814afe75b085a8b88aab74fd3a922aa98180c447457dfc4174515513181c5f4edc521978a1d3d0a112106c98b5c73c0e
2020-02-09depends: Remove reference to win32MarcoFalke
win32 is no longer mentioned in doc/build-windows.md
2020-02-06build: don't embed a build-id when building libdmg-hfsplusfanquake
2020-02-03build: use macOS 10.14 SDKfanquake
Co-Authored-By: Carl Dong <accounts@carldong.me>
2020-02-03depends: native_cctools 921, ld64 409.12, libtapi 1000.10.8fanquake
This also removes the obsolete mlinker-version option Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-08 12:42:25 +0000