Age | Commit message (Collapse) | Author |
|
|
|
f9af3ced1c69d65c5c530ec5526f5eefaf786126 Android: add all arch support (Block Mechanic)
d419ca7e32bfc71e8dd1f1b91870463eacd6ad8e depends: export dynamic JNI symbols from static qtforandroid.a (Igor Cota)
ed30684d03d3a1d5496e69c488d848fe92ae6fb4 Qt: patch androidjnimain.cpp to make sure JNI is initialised when statically compiled (Igor Cota)
e4c319e8a1c6e40a953036b942bd5d732b0bbf69 builds: remove superfluous config_opts_aarch64_android (Igor Cota)
24ffef0c271739a2ca75feecb816f3218c1850bf Patch libevent when building for Android (fix arc4random_addrandom) (Igor Cota)
f1e40b3e7114b18bc03f45c3a97f9f673543ddef Update bitcoin_qt.m4 (BlockMechanic)
b4057d82618a21720f39f448b689cebf475cc2dc Define TARGET_OS when host is android (Igor Cota)
80b475f159525737e242161397f35d0729449545 Fix Android zlib cross compilation issue (https://stackoverflow.com/questions/21396988/zlib-build-not-configuring-properly-with-cross-compiler-ignores-ar) (Igor Cota)
45f82190150b3feef333724ea7395ba080e700b1 Add full Android build example command and instructions on getting SDK/NDK (Igor Cota)
b68f2a68c211aa2264e9ca824d10a90f4a5a5af4 Add config opts and patch for aarch64_android build of Qt (Igor Cota)
9c4cb0166e801471f8cb3d82656c86bacf051db6 Add ranlib to android.mk hosts file (fix OSX Android NDK build) (Igor Cota)
c2a749c9c16697e744ecfb283fdf4095d0278066 Add example Android host-platform-triplet and options (Igor Cota)
0b0cff3c61610fb56f8c5c9451ace01598117a8d 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
|
|
compiled
|
|
|
|
463a1d5244337915de36db36de573eb8782bc430 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 463a1d5244337915de36db36de573eb8782bc430 - 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 can actually patch QT to remove its dependency on libX11's headers.
It turns it this wasn't that hard.
|
|
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.
|
|
functions
|
|
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.
|
|
|
|
Backport of https://bugreports.qt.io/browse/QTBUG-62511 to resolve
locale determinism during the build process.
|
|
|
|
Apply patch from QTBUG-67286
|
|
Depends can now be built with Qt5.9.4 , which is Qt's new long term
support version.
|
|
|
|
|
|
|
|
|
|
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.
|
|
This also fixes the native osx build.
|
|
|
|
|
|
|
|
64047f8 depends: Add libevent compatibility patch for windows (Wladimir J. van der Laan)
|
|
|
|
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.
|
|
Core no longer supports Qt 4. Therefore, the STL fix patch isn't needed.
|
|
|
|
The non-deterministic ordering produced by biplist ends up in the .DS_Store
file that is included in the OSX dmg.
|
|
|
|
This fixes the gitian MacOSX build, it was broken in #7723.
The patch to `native_mac_alias` should probably make it upstream.
|
|
Superseded by 4bdad99f5000539dcf03ddc92c142fa6deb44c01
|
|
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).
|
|
Make it possible to reuse sockets.
This is necessary to make the RPC tests work in WINE.
|
|
|
|
|
|
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:
https://github.com/boostorg/config/commit/eec808554936ae068b23df07ab54d4dc6302a695
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.
|
|
|
|
|
|
We're not ready to switch to a static qt5 for Linux yet due to missing plugin
support. This adds a recipe for building a shared qt4 that we build and link
against, but don't distribute.
make USE_LINUX_STATIC_QT5=1 can be used to build static qt5 as before.
|