02ac445b2f bump libevent to 2.1.11 in depends (stefanwouldgo)
Pull request description:
this doesn't need patches on Android anymore like 2.1.8 did.
ACKs for top commit:
laanwj:
ACK 02ac445b2f
Tree-SHA512: 1fbfe342ee15fa4c5cb417979bd6c443f7c7aa40a489accf8ccd7c919e5b08e859b3da6edeee3de484f6f156b35dd4e97c7e2c7971b59fc31029865585ccb296
f9af3ced1c Android: add all arch support (Block Mechanic)
d419ca7e32 depends: export dynamic JNI symbols from static qtforandroid.a (Igor Cota)
ed30684d03 Qt: patch androidjnimain.cpp to make sure JNI is initialised when statically compiled (Igor Cota)
e4c319e8a1 builds: remove superfluous config_opts_aarch64_android (Igor Cota)
24ffef0c27 Patch libevent when building for Android (fix arc4random_addrandom) (Igor Cota)
f1e40b3e71 Update bitcoin_qt.m4 (BlockMechanic)
b4057d8261 Define TARGET_OS when host is android (Igor Cota)
80b475f159 Fix Android zlib cross compilation issue (https://stackoverflow.com/questions/21396988/zlib-build-not-configuring-properly-with-cross-compiler-ignores-ar) (Igor Cota)
45f8219015 Add full Android build example command and instructions on getting SDK/NDK (Igor Cota)
b68f2a68c2 Add config opts and patch for aarch64_android build of Qt (Igor Cota)
9c4cb0166e Add ranlib to android.mk hosts file (fix OSX Android NDK build) (Igor Cota)
c2a749c9c1 Add example Android host-platform-triplet and options (Igor Cota)
0b0cff3c61 Add support for building Android dependencies (Igor Cota)
Pull request description:
This allows one to build the dependencies with the Android SDK and goes towards fixing #11844. It has been tested to work with:
`make HOST=aarch64-linux-android ANDROID_API_LEVEL=28 ANDROID_TOOLCHAIN_BIN=/home/user/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin NO_QT=1 NO_WALLET=1`
ACKs for top commit:
Sjors:
ACK f9af3ce. I'm OK with merging and then improving later.
Tree-SHA512: cb805115ebe5c9e33db2bf3eab8628808fe3f50052053d8877d8b8e4406d6fea1ed9e5c4dff85d777fb99c81be6ffb9d95a0e6d32344e728e5e0da6c653e2ce7
463a1d5244 Refresh ZeroMQ 4.3.1 patch (Nathan Marley)
Pull request description:
Currently in Alpine Linux (latest, 3.10) in the depends system, one of the ZeroMQ patches won't apply cleanly because the context around the patch has changed and Alpine's `patch` implementation can't handle the diff.
Some patch implementations can't handle fuzz / too much divergence from the original code.
This PR just tweaks the context code around the patch so that less-sophisticated patch implementations (such as on Alpine Linux) can apply the patch without errors.
This partially fixes#16925
ACKs for top commit:
fanquake:
ACK 463a1d5244 - Tested building zeromq in depends inside an [Alpine container](https://github.com/fanquake/core-review/blob/master/docker/alpine.dockerfile) as well as on macOS.
Tree-SHA512: d6e3cb60835cdd090b9b864ca9cb33961687606bc9184fbbeb7a54ec23db4057b9317b65c5c276fb8c5492cb3cfcc4a7f3369f049551f4eb0915db971f2290ce
Some patch implementations can't handle fuzz / too much divergence from the
original code.
This just tweaks the context code around the patch so that less-sophisticated
patch implementations (such as on Alpine Linux) can apply the patch without
errors.
We're no longer building QT with libX11/XLib, however, libX11/XLib
headers are still required for parts of QT. In this commit we add a
minimal configure.ac for libX11/XLib that is headers-only.
This change allows us to remove all of libX11/XLib's dependencies.
Qt's configure grabs the path to xkb's data root during configure, but the
build changes in 5.8 apparently broke the handling for cross builds. As a
result, the string embedded in the binary depends on whether or not some files
are present in the builder's filesystem.
The "-xkb-config-root" configure setting is intended to allow manual overriding
but it is also broken. See: https://bugreports.qt.io/browse/QTBUG-60005
This has since been fixed upstream, so just hard-code the path for now. We can
drop this patch when we bump to a fixed Qt.
Also, fix the "-qt-xkbcommon-x11" config param which was renamed. This does not
appear to affect build results, presumably because auto-detection is working,
but it does not hurt to be explicit.
The patch Bitcoin Core has been maintaining for mac_alias was pulled by the mac_alias maintainer in commit 4f31cb084c1c6a8626128b0b00842020b6db9037. Delete the patch and remove the patch from the depends system.
Note that this PR won't be complete until a new version of mac_alias containing the path has been released, and the depends system is updated to reflect the new version.
This contains a few hacks very specific to Qt's buildsystem. These can be
reverted once we split the build between native and target builds.
Qt's build contains a circular dependency when not using a system zlib.
By far the easiest fix is to switch to a system zlib, rather than Qt's own.
However, that confuses Qt's cross build which assumes that when using a system
zlib, it should also find a system (native) zlib for native tools. The build
breaks if that zlib is not present.
To solve this:
1. Always use a system zlib rather than the one provided by qt
2. Set force_bootstrap, which instructs the build tools to be built as though
we're cross-compiling (build != target)
3. For build tools, use qt's internal zlib so that a native zlib is not
required.
Step 3 means that if any zlib headers are found by the native build, it will
confuse Qt's internal zlib build. So we also need to make sure that the target
headers/libs aren't found. To do so, specify that our
cflags/cxxflags/cppflags/ldflags only apply for non-host builds.
Add a patch that seems to be necessary for compatibilty of libevent
2.0.22 with recent mingw-w64 gcc versions (at least GCC 5.3.1 from Ubuntu
16.04).
Without this patch the Content-Length in the HTTP header ends up as
`Content-Length: zu`, causing communication between the RPC
client and server to break down. See discussion in #8653.
Source: https://sourceforge.net/p/levent/bugs/363/
Thanks to @sstone for the suggestion.
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).
Boost assumes variadic templates are always available in GCC 4.4+, but
they aren't since we don't build with -std=c++11.
This applies the patch that fixed the issue in boost 1.57:
eec8085549
See also: https://svn.boost.org/trac/boost/ticket/10500
See here for background: https://bugreports.qt.io/browse/QTBUG-34748
libxcb temporarily had an abi breakage which caused crashes when qt was
compiled against a non-compatible version. Building qt with -qt-xcb should have
shielded us from this issue, except that incompatible headers were used when
building qt's wrapper.
Make sure those headers aren't picked up by qt's build.
Details:
qt's build adds a wrapper around the xcb libs when -qt-xcb is used. This is
done to avoid having to link to a handful of different libs, which may not be
api/abi stable. This build depends on include-order, so that its files are
found before the real libxcb headers.
Our build (for other reasons related to qt's complicated build-system) injects
our prefix into CXXFLAGS. Because libxcb is found in this path, that reverses
the include-order, negating the purpose of the wrapper.
To fix, libxcb's includes are simply moved to a subdir. pkg-config ensures that
they're still found properly when needed.
To make things even more interesting, this behavior in qt's .pro files is broken:
INCLUDEPATH += $$QMAKE_CFLAGS_XCB
The INCLUDEPATH variable is processed by qmake which automatically prefixes each
entry with "-I". The QMAKE_CFLAGS_XCB variable comes from pkg-config and
already contains -I, making the path look like "-I-I/path/to/xcb/headers".
To work around that, CFLAGS/CXXFLAGS are used here rather than INCLUDEPATH.
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.
Wladimir J. van der Laan