Age | Commit message (Collapse) | Author |
|
|
|
|
|
Update FreeType, and change the download location to gnu.org. This is
the other official download location listed on freetype.org
|
|
|
|
All trusty compilers work ok with this now, and it shaves a few minutes off of
build time
|
|
This fixes the gitian MacOSX build, it was broken in #7723.
The patch to `native_mac_alias` should probably make it upstream.
|
|
Checksums were being verified after download, but not again before extraction
|
|
2016/01/24:
Change miniwget to return HTTP status code
Increments API_VERSION to 16
2016/01/22:
Improve UPNPIGD_IsConnected() to check if WAN address is not private.
Parse HTTP response status line in miniwget.c
|
|
|
|
atomic_init clashes with
|
|
|
|
|
|
e0769e1 [depends] Latest config.guess & config.sub (fanquake)
23a3c47 [depends] zeromq 4.0.7 (fanquake)
10d3c77 [depends] Fix miniupnpc compilation on osx (fanquake)
26f8ea5 [depends] native ccache 3.2.4 (fanquake)
17ad964 [depends] miniupnpc 1.9.20151026 (fanquake)
9e940fa [depends] Boost 1.59.0 (fanquake)
|
|
2798e0b add powerpc build support for openssl lib (daniel)
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
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:
https://github.com/miniupnp/miniupnp/commit/79cca974a4c2ab1199786732a67ff6d898051b78
Reported by timothy on IRC.
|
|
42cf089 depends: bump ccache to 3.2.3 (fanquake)
888c595 depends: bump miniupnpc to 1.9.20150730 (fanquake)
|
|
prefix instead of postfix
|
|
|
|
Make it possible to reuse sockets.
This is necessary to make the RPC tests work in WINE.
|
|
|
|
|
|
|
|
|
|
|
|
Helps ease of reading and comparison. Removed some duplicates.
|
|
|
|
Also change the download source from googlecode to github.
|
|
|
|
|
|
|
|
This should fix the spurious comparison tool failures.
See discussion here: https://github.com/bitcoin/bitcoin/pull/6305
The race fix was cherry-picked on top of the version we're currently using, so
it should be functionally identical otherwise.
|
|
This should be functionally identical to what's in place now. It was built from
https://github.com/theuni/bitcoinj/commit/be0eef774462409df277b2a83d71c30451f107c5
That commit is the same as this pruned commit in TheBlueMatt's repo:
https://github.com/TheBlueMatt/bitcoinj/commit/0f7b5d8
Now we'll be able to trust the line numbers in the stack traces.
|
|
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
|
|
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.
|
|
|
|
Chery-picked from 0.10 branch.
Rebased-From: c3200bcd1e7116e079aebabed3a01dc5385bfc9e
|
|
|
|
This one no longer requires native libuuid or libcrypto
|
|
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.
|
|
|
|
|