Ugrade Qt depends to Qt5.9.4
Depends can now be built with Qt5.9.4 , which is Qt's new long term
support version.
Fix depends Qt5.9.4 mac build
Apply patch from QTBUG-67286
Upgrade Qt depends to 5.9.6
00db418176 Add aarch64 qt depends support for cross compiling bitcoin-qt (TheCharlatan)
Pull request description:
This also adds a generic qt linux target in packages.mk . I am a bit confused by the existing docs for the RISC addition. Are there boards that would support running bitcoin-qt, or at the very least forwarding X over ssh? Is everybody building depends with `NO_QT=1` when targeting RISC? If not, I will revert the change for a generic qt linux package definition back to the piecemeal solution.
This pull request should close#13495
Tree-SHA512: 519b951bf50f214ad725e5330094582a212333cd85b0ae442c67f9afec5629995dfad130258c7706a61f7b7cccbfa49bce69b9931f7e30cf12b382cd9a0a4749
12c93cb85b depends: use MacOS friendly sed syntax in qt.mk (Sjors Provoost)
Pull request description:
I just got this error on master:
```
make clean-all
make -j5
[...]
/bitcoin/depends/sources/qttools-opensource-src-5.9.6.tar.xz: OK
Preprocessing qt...
sed: 1: "qtbase/mkspecs/bitcoin- ...": extra characters at the end of q command
make: *** /bitcoin/depends/work/build/x86_64-apple-darwin17.7.0/qt/5.9.6-b48df1b490b/.stamp_preprocessed] Error 1
```
Tree-SHA512: 1eaee535c0d637a67801c7dd48e9cd5a037823f4e162a6f50e375787045fdb95929f409a88c7d000d8781a4edc497b5ccb1fd23a24e29324ec633157fadd371e
4b6998455776ed3e1b7c996c14f15f0c304c9269 Add depends 32-bit arm support for bitcoin-qt (Sebastian Kung)
Pull request description:
Some hobbyists are used to using the desktop for interfacing with their raspberry pi. This commits adds qt to the arm-linux-gnueabihf target.
Tree-SHA512: cb03387267eb8f68dfd79735c2c01c5a119c406e5578805e60b377934da42d46cb34d35e45c8843979dfb4070859c553d09ae348b468d9731523f33307132fa8
We may eventually want to break out harfbuzz and build it in depends, but
for now just ensure that runtime dependencies don't depend on whether or not
harfbuzz was present on the builder.
Setting PKG_CONFIG_SYSROOT_DIR environment variable to "/"
for building Qt makes pkgconf behave strange
(remove "/" prefix instead of adding it).
And it makes no sense to set this variable for old pkgconfig anyway.
Signed-off-by: Oleg Girko <ol@infoserver.lv>
* build: Enable C++11 build, require C++11 compiler
Implements #6211.
* depends: use c++11
* build: update ax_cxx_compile_stdcxx to serial 4
* build: force a c++ standard to be specified
Newer compilers may switch to newer standards by default. For example, gcc6
uses std=gnu++14 by default.
* c++11: fix libbdb build against libc++ in c++11 mode
atomic_init clashes with
* c++11: CAccountingEntry must be defined before use in a list
c++11ism. This fixes builds against libc++.
Remove sed-based qt PIDLIST_ABSOLUTE workaround, replace by a patch that
works for both old (such as used by Travis and Ubuntu Precise) and new
mingw (Ubuntu Trusty).
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
Fixes default hidden symbol visibility for our linux->osx cross build. Without
this change, the check for working -fvisibility=hidden fails, and all symbols
are visible by default.
Ugly as this is, it's just a simple find/replace to fix a bug in Qt's configure.
They assume in an "XPLATFORM_MAC" block that the builder is capable of running
osx programs. This should be "BUILD_ON_MAC" instead.
