Changes the fallback dependency source repository from Bitcoin's
bitcoincore.org to dogecoincore.org. Both are centrally hosted,
as a fallback. Ideally this would be utilizing a decentralized
protocol like IPFS, but this is harder to integrate with the CI
tooling.
Note: because some dependencies have identical filenames in their
source URLs (currently ds_store and mac_alias) we host the target
filename on the mirror, to prevent conflicts.
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>
Instead of doing the awkward /bin path prepending at config.site
creation time, set darwin_{CC,CXX} in a way that fully determines the
program's path (clang/clang++)
Also see the added comment block in depends/Makefile for more context on
determining $PATH for our config.site.
Cherry-picked from: 880660ac
Conflicts: cherry-picked from a Bitcoin Core build system that is
optimized for supporting system-provided clang builds
which Dogecoin Core does not have at this time. I have
removed all code regarding that functionality and only
kept the code relevant to Dogecoin Core for this
major version (1.14), i.e. those lines that use the
pinned clang from the depends system.
Patches openssl 1.0.2's usage of secure_getenv to always use the
fallback OPENSSL_issetugid() instead, to remove reliance on a
higher glibc than the minimum we currently support (2.11)
See depends/patches/openssl/secure_getenv.patch for a full
description of the patch.
These patches must be applied to the bdb-5.1.29 source from Oracle, and then compiled, for the Mac client to build.
Using an existing 5.1.29 binary will not work; as it was likely compiled with gcc; which OSX no longer natively supports.
* 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
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.
Github-Pull: #9891
Rebased-From: 9e4d842afc67c63448cbbe30e5cea906e9c87f7e
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.
