- openssl (was only needed for BIP70/71)
- http and network modules (Qt no longer implements any networking)
- qt socks integration (does not affect p2p socks routing)
We do not need libx11 to compile Qt with some very minor patches.
Removing this removes attack surface from dogecoin-qt and reduces
future maintenance cost.
- Removes packages:
- libX11
- libXext
- xextproto
- xtrans
- Patches Qt to not try to include X11 anywhere
- Removes x11-xcb check from bitcoin_qt.m4
- Remove permission to depend on libX11*so in release binaries
Backported-from: 1ec30b8f
aa53cb7a
92456991
0c55d8b5
689d3b4a
Co-Authored-By: Carl Dong <contact@carldong.me>
dbus is not used by qt in depends per documentation of the
-dbus-runtime configuration flag - it uses the packaged interface
and can be removed as a managed dependency.
Since dbus interfaces are only used on linux, remove it from the
windows and macOS configurations.
Backported-from: e8fabd92
6fdf5dab
Co-authored-by: fanquake <fanquake@gmail.com>
Remove functionality of Qt that we do not need, resulting in a
smaller dogecoin-qt binary and a reduced attack surface.
- removes all image support except png
(xpm is needed for qt binary build tools)
- no longer use Qt's built-in libjpeg
- disable all unused features
Items that cannot be removed vs Bitcoin Core:
For paper wallets:
- printer dialogs and pdf
- html rendering
For BIP70 payment requests:
- network configuration
- openssl
- socks5 support
For normal users, --no-same-owner is default, but not so for root, where
it is assumed that root can change ownership willy-nilly. This is not
the case for privilege-limited container environments where we gaslight
the process into thinking it's root.
Cherry-picked from: 89bee1b
-After updating clang+llvm, QT 5.7.1's qfontengine_coretext.mm file's variable QFixed errors out as it's a constructor rather than a type in this context. This patch fixes that error.
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.
Cherry-picked from: bitcoin/bitcoin 3272e34f
and bitcoin/bitcoin cc25f892
and bitcoin/bitcoin a33381ac
Conflicts resolved:
- removed ci script and guix file changes that we don't have
- removed changes to libxcb
- squashed commits as cc25f892 was a fixup
- rewrote the change to depends/README
Co-authored-by: fanquake <fanquake@gmail.com>
Co-authored-by: W. J. van der Laan <laanwj@protonmail.com>
* Add paper wallet generator to QT wallet
* Replace print icon with Typeicons equivalent
* Re-add printer support to Qt
* depends: fix fontconfig with newer glibc
See comment for more detail
* Set fixed size for paper wallet dialog
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.
qt5.7 changed the location of some of its symbols, creating a circular
dependency in Qt5Core. Rather than trying to fix that up, build our own zlib
rather than having it built for us.
Their buildsystem insists on using the installed ltranslate, but gets confused
about how to find it. Since we manually control the build order, just drop the
dependency.
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.
