Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
This change partially reverts 248e22bbc0d7bc40ae3584d53a18507c46b0e553.
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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
|
|
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.
|
|
|
|
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
|
|
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.
|
|
This gets us a newer SDK with c++17 support and retains 10.12
back-compat.
Co-authored-by: Carl Dong <contact@carldong.me>
|
|
clang 6.0.1 -> 8.0.0
cctools 921 -> 949.0.1
ld64 409.12 -> 530
|
|
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.
|
|
|
|
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
|
|
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
|
|
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.
|
|
|
|
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.
|
|
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
|
|
For example, doing:
make CC=clang CXX=clang++
Should now propagate these settings down to depends packages
|
|
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.
|
|
Builds required packages and passes --enable-multiprocess option to bitcoin build
|
|
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.
|
|
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.
|
|
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
|
|
|
|
|
|
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)
|
|
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
|
|
|
|
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
|
|
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
|
|
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
|
|
win32 is no longer mentioned in doc/build-windows.md
|
|
|
|
Co-Authored-By: Carl Dong <accounts@carldong.me>
|
|
This also removes the obsolete mlinker-version option
Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
|
|
This also removes some now-unnecessary cctools hacks.
Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
|
|
|
|
All other mk files use the package variable consistently except for the two instances here, which have always been here, since depends was introduced in 0.10.
|
|
|
|
|
|
|
|
e97f5c18238835bc3a3aee2e9e65b287f1c8b938 depends: don't configure xcb_proto (fanquake)
Pull request description:
xcb_proto's configure doesn't understand `--disable-shared` or
`--with-pic`. All the package does it put a stack of XML files into
a directory to be used by libxcb.
Probably enough to close #16354.
ACKs for top commit:
dongcarl:
ACK e97f5c18238835bc3a3aee2e9e65b287f1c8b938
Tree-SHA512: 1a49fd7c8269405bbf312be33c1aeaac5f25ef8666829b01dc3c58f3a2a9281c23c42614a7f1cfc3ee260be4ea3e71285869b1cb9c2035dceda336296d9d9dea
|