A few years ago, libfreetype introduced FT_Get_Font_Format() as an alias for
FT_Get_X11_Font_Format(), but FT_Get_X11_Font_Format() was kept for abi
backwards-compatibility.
Our qt bump to 5.9 introduced a call to FT_Get_Font_Format(). Replace it with
FT_Get_X11_Font_Format() in order to remain compatibile with older freetype,
which is still used by e.g. Ubuntu Trusty.
Github-Pull: #14348
Rebased-From: 430bf6c7a1
Tree-SHA512: fd22b824e7251a7975d9e9222eff06d2b04ebf30e13aeccab580596c042b3abe2f62da1f0ef75106b0b171368ee1062ef2f459cfa435aa54826766a9005b80df
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.
Github-Pull: #14000
Rebased-From: de0b4fba2f
6b5506a286 Fix Qt's rcc determinism for depends/gitian (Fuzzbawls)
Pull request description:
With the update to Qt 5.9 having been merged, Qt's `rcc` tool now embeds a file's last modified time in it's output. Since the build system generates temporary files for all locale translations (`*.qm` files) at build time, the resulting `qrc_bitcoin_locale.cpp` file was always being generated in a non-deterministic way.
This is a backport of https://bugreports.qt.io/browse/QTBUG-62511, which is included in Qt versions 5.11+, that allows for an environment variable (`QT_RCC_SOURCE_DATE_OVERRIDE`) to override the behavior described above. This environment variable is in turn set in the gitian descriptors, as that is where determinism is vital for release purposes.
Prior to this, the `qt_libbitcoinqt_a-qrc_bitcoin_locale.o` object file (included into `libbitcoinqt.a`) was returning a different `sha256sum` for each and every build, regardless of file contents change, thus breaking determinism in the resulting binaries.
This should fix#13731
Tree-SHA512: 174017e41f9afc3950ef54a9419de81577ec900db9aec3c78ccd3d879c6aecaaeb944fde0615b933f43e6ca9d7898a27ec071cdd0b91cb772755a3012de96725
f447a0a707 Remove program options from build system (Chun Kuan Lee)
11588c639e Replace boost program_options (Chun Kuan Lee)
Pull request description:
Concept from #12744, but without parsing negated options.
Tree-SHA512: 7f418744bb8934e313d77a5f162633746ef5d043de802b9c9cd9f7c1842e7e566eb5f171cd9e2cc13317281b2449c6fbd553fa4f09b837e6af2f5d2b2aabdca2
4b69984557 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
974f0bf8e6 depends: Mention RISC-V known compilation issue with gcc-7.3.x (Wladimir J. van der Laan)
0d1f38c45f depends: update zmq config.guess/config.sub for riscv support (fanquake)
409481c465 depends: latest config.sub (fanquake)
d7005e9988 depends: latest config.guess (fanquake)
359e2e3525 depends: Add RISC-V support (Wladimir J. van der Laan)
Pull request description:
This adds support for riscv32 and riscv64 builds to the depends system.
The change consists of documentation and build system changes. The most significant change is an update of `config.sub` and `config.guess` inside zeromq patch, as the current version does not recognize the `riscv*` host tuples (there's no new version of ZeroMQ yet with newer ones).
Good thing: RISC-V 64-bit toolchain packages can be installed out of the box on Ubuntu 18.04+.
I would also like to add RISC-V 64-bit executables to gitian, but this will not be possible until #12511 .
Tree-SHA512: 358ed72ee9e4ae44e7d305c09a4ff5ce5460eeb7ed915eb25d39c8f43b61e7b347f51bf0ae5d83ddb4ce8876dea7703c926b3baa3cccb4932b3bc17160d801bb
4ef82f1 depends: biplist 1.0.3 (fanquake)
Pull request description:
biplist should now be usable for reproducible builds without any patching.
One change has been incorporated, the two remaining changes were rejected upstream: https://bitbucket.org/wooster/biplist/pull-requests/9/make-biplist-ordering-deterministic/diff#comment-None
testing on gitian cc @jonasschnelli
Tree-SHA512: a3ef3ecad08b09f7a34d927bc4e3d8604099e9acb2c984bbe741df6162f4014f40e9eb2fd28309fc79d3dd2bb82f14bfd473925b90048e5fd135a471726a4836
cc879675e1 depends: Remove ccache (fanquake)
Pull request description:
After discussion with @theuni, we can possibly just remove ccache from depends entirely.
Related to #12606
Tree-SHA512: ae0a60c8d97467fa41d617daa48ed22159cf32613808634a983304901dd5ed27124e77868d2314004e5144f7b35ba1333f720bb12daec4c5ca03aaf29d593ef2
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 is broken for a number of reasons, including:
- g++ understands "-static-libstdc++ -lstdc++" to mean "link against whatever
libstdc++ exists, probably shared", which in itself is buggy.
- another stdlib (libc++ for example) may be in use
ld64 is threaded, and uses a worker for each CPU to parse input files. But
there's a bug in the parser causing dependencies to be calculated differently
based on which files have already been parsed.
As a result, builders with more CPUs are more likely to see non-determinism.
This looks to have been fixed in a newer version of ld64, so just disable
threading for now. There's no noticible slowdown.
