In some cases, such as for github revision tarballs, the upstream
filename is just ``$HASH.tar.gz``, but the local filename is
``${PACKAGE_NAME}-${HASH}.tar.gz``. With this patch, it's clear which
packages each URLs provides *and* it makes the process of updating
http://z.cash/depends/sources a simple scp rather than involving some
kind of name translation.
Closes#622.
Some specifics on consensus changes:
* Transactions must be anchored to a real anchor in the chain.
* Anchors are pushed and popped during ConnectBlock/DisconnectBlock as appropriate.
* DisconnectTip triggers evictions, under some circumstances, of transactions in the
mempool which are anchored to roots that are no longer valid.
* Commitments append to the tree at the current best root during ConnectBlock.
This passes `-Wa,--noexecstack` to the assembler when building
platform-specific assembly files, to signal that a non-executable stack
can be used. This is the same approach as used by Debian
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430583)
Rebased-From: bfcdc21a5da25ec1aa4aecc4cd8960dfa1c11781
Github-Pull: #6852
This version of miniupnpc fixes a buffer overflow in the XML (ugh)
parser during initial network discovery.
http://talosintel.com/reports/TALOS-2015-0035/
The commit fixing the vulnerability is:
79cca974a4
Reported by timothy on IRC.
Github-Pull: 6789
Rebased-From: 0cca0248f030ea32bd8de778b5a2782e0d191978
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
Github-Pull: #6280
Rebased-From: b19a88b2a0e7bd9ef603055bc8e1ef058673025d
Documentation more readable when viewed on Github.
Some extra changes by @laanwj:
- Make README.usage the default README. This is more convenient from a
user perspective. Link to other documentation in this default README
- Add list of popular targets for cross compilation, change default to
Win64 instead of Win32
In some cases (Travis), sources and build caches may be moved around in-between
builds, and we can't necessarily trust that everything is still intact.
This introduces pre-build checks that verify against stashed checksums.
Note that this will cause all sources to be re-downloaded, since cached sources
weren't trustworthy before this.
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.
Broken hash logic caused all depends on some platforms (osx at least) to end up
with the same build-id. Without this fix, nothing will be rebuilt when recipes
or dependencies change.
Since the last commit will force rebuilds of all depends, take the opportunity
to clean up a few other things that would trigger rebuilds as well.
- Move source stamps to the sources dir so that SOURCES_PATH is respected for
"make download".
- Only print "fetching..." when actually downloading a file.
- Avoid using non-deterministic paths for the recipe hash (patch location).
This should ensure that all builders get the same resulting build-ids.
- Use a per-package source paths. This will allow for removing old source files
in the future.
- Use a host-agnostic path for downloads which gets cleaned up properly.
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.
Descriptors now make use of the dependencies builder, so results are cached.
A very new version (>= e9741525c) of Gitian should be used in order to take
advantage of caching.
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.
Sean Bowe