gitian: build on ubuntu 14.04 #6900

laanwj · 2015-10-29T08:29:30Z

This changes the VM environment for gitian building to use Ubuntu 14.04 (Trusty).

Changes compiler version from GCC 4.6 to GCC 4.8, which makes RFC: switching to C++ 11 #6211 (using the relevant subset of c++11) possible, and probably results in better code
Removes some 12.04 specific cruft from descriptors
The security and symbol checks pass (symbol check reports clock_gettime, but this is the same for old descriptors thus unrelated)
Linux and OSX and Windows output is deterministic

Known problems:

Windows build is not deterministic

SOLVED

Every link, a few bytes in the executable near the end of .rodata are different. These are not a timestamp but apparently random.

I spent some time tracking this down, eventually used a linker map to find that the bytes come from a ephermal object ertr000001.o. This helped trace this problem to the function pe_create_runtime_relocator_reference in binutils/ld/pe-dll.c which leaks a few bytes of heap to the executable by writing uninitialized data (!).

This sounds serious, however apparently this was already solved by the Erinn Clark of the Tor project in 2013: https://sourceware.org/bugzilla/show_bug.cgi?id=16192 . Awesome.

Unfortunately Ubuntu hasn't included the new binutils in 14.04... @theuni any idea how to handle this? Tor, for a while, manually patched the bytes (well not manually I suppose - in a postprocessing step). Another option would be to use our own binutils, or use an even newer image (but that wouldn't be long term supported).

wtogami · 2015-10-29T18:59:17Z

Does this change the minimum compatible system glibc/libstdc++ version of the Linux binary? If the new glibc or libstdc++ added new symbols @theuni may need to add more wrappers to the compat library.

laanwj · 2015-10-29T20:40:46Z

Does this change the minimum compatible system glibc/libstdc++ version of the Linux binary?

It shouldn't. That's what the symbols check (contrib/devtools/symbols-check.py) checks for.

theuni · 2015-10-30T02:52:56Z

Well that was easy :)

For Windows, patching seems like it'd be the easiest, but I'd worry about breaking checksums. I suppose if Tor did it that way, either it's not an issue or updating the checksums is doable as well. Will look into it.

@sipa mentioned on IRC that depends are currently broken for him on his dev machine, and the fix is the change you made here to qt.mk. Rather than removing the hackish sed, let's make a patch which properly ifdefs, so that it'll work on old/new mingw.

Also, I'd be more comfortable with this if we could wait for Trusty on Travis. I've pinged them to try to get an idea of a timeline. Obviously if it's going to drag on too long, we can just bump the compiler versions we use in our current env in order to simulate a bump to Trusty.

laanwj · 2015-10-30T09:00:26Z

For Windows, patching seems like it'd be the easiest, but I'd worry about breaking checksums. I suppose if Tor did it that way, either it's not an issue or updating the checksums is doable as well. Will look into it.

Tor uses 'strip' to recompute the checksum. I'm not sure what they used to find the index of the bytes, as it is not a fixed offset into any section in the final file. Maybe they used the linker map like me. We could ask them.

Rather than removing the hackish sed, let's make a patch which properly ifdefs, so that it'll work on old/new mingw.

Right - Qt did an attempt at this, but they apparantly got the version threshold wrong. Though it is not impossible that Ubuntu complicated this by backporting things into older releases. From qwindowsdialoghelpers.cpp:

/* The correct declaration of the SHGetPathFromIDList symbol is
 * being used in mingw-w64 as of r6215, which is a v3 snapshot.  */
#if defined(Q_CC_MINGW) && (!defined(__MINGW64_VERSION_MAJOR) || __MINGW64_VERSION_MAJOR < 3)
typedef ITEMIDLIST *qt_LpItemIdList;
#else
typedef PIDLIST_ABSOLUTE qt_LpItemIdList;
#endif

Or maybe it is correct! this kind of armoring is missing completely for the use of PIDLIST_ABSOLUTE in qwindowscontext.h, and that is what Travis is failing on.

Also, I'd be more comfortable with this if we could wait for Trusty on Travis

I'd like so, too. Depends on the time frame - IMO it would be nice to build 0.12 using the new compiler, as it appears to be pretty much a hassle free upgrade.

laanwj · 2015-10-30T09:04:23Z

OK, this is Tor's workaround.

  # XXX: What the hell are these three bytes anyways?
  sed 's/\x94\x0C\xE7\x6A\xB8\x0C\xE7\x6A\x08...\x04\xBA\xCB\x7E/\x94\x0c\xe7\x6a\xb8\x0c\xe7\x6a\x08\x23\x23\x23\x04\xba\xcb\x7e/M' -i $INSTDIR/App/Firefox/xul.dll
  sed 's/\x94\xb1\x24\x65\xb8\xb1\x24\x65\xf8...\x04\xba\xcb\x7e/\x94\xb1\x24\x65\xb8\xb1\x24\x65\xf8\x23\x23\x23\x04\xba\xcb\x7e/M' -i $INSTDIR/App/Firefox/gkmedias.dll
  # Stripping again updates the PE header checksums to be correct
  i686-w64-mingw32-strip $INSTDIR/App/Firefox/gkmedias.dll
  i686-w64-mingw32-strip $INSTDIR/App/Firefox/xul.dll

Using sed for binary patching is not anything I've seen before, or would necessarily encourage (fragility as the surrounding data may move).
All trace of this is gone in their new builders, so I assume they use a newer version now: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/descriptors/windows/gitian-firefox.yml

They're patching binutils: https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/gitian/descriptors/windows/gitian-firefox.yml?id=fd14de1870b38987c25eba1d3f8ca87b22f3bb8b
Then they commented out the hacks: https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/gitian/descriptors/windows/gitian-firefox.yml?id=95446ee9fef932ba2c443968a90b650a36cd2182

laanwj · 2015-10-30T12:52:15Z

Wrote a script that overwrites the bytes given an executable and linker map, then calls strip to recompute the checksum. It was somewhat more involved than I thought as it has to parse the PE sections to find the file offset: https://gist.github.com/laanwj/01dc996c4755d19e134e

But it works for 32/64 bit, tested using

#!/bin/bash
$1 mtest.c -o mtest_1 -Wl,-Map=mtest.map
$1 mtest.c -o mtest_2 -Wl,-Map=mtest.map                                                                    
$1 mtest.c -o mtest_3 -Wl,-Map=mtest.map                                                                    
sha256sum mtest_1 mtest_2 mtest_3                                                                                           
~/projects/bitcoin/bitcoin/contrib/devtools/bitstomp.py  mtest_1 mtest.map
~/projects/bitcoin/bitcoin/contrib/devtools/bitstomp.py  mtest_2 mtest.map                                                    
~/projects/bitcoin/bitcoin/contrib/devtools/bitstomp.py  mtest_3 mtest.map                                                    
sha256sum mtest_1 mtest_2 mtest_3

$ ./mtest.sh i686-w64-mingw32-gcc
570f42e57f2a5b864f2464eab5f9e49d64545f36992f8429c6a2555ec29272ed  mtest_1
ab53006e857d3e8eb14d380a94cdc0a6cc9291a1d4a284961c5fd323bd915dec  mtest_2
46e6caae3a29378b0bd023124c4000856f6049c4a0602ff599aa2b6035417fa1  mtest_3
mtest_1: Patching e8833007 to 00000000 at offset 0000205c (virtual address 000000000040425c)
mtest_2: Patching e8735bdb to 00000000 at offset 0000205c (virtual address 000000000040425c)
mtest_3: Patching e8638e8d to 00000000 at offset 0000205c (virtual address 000000000040425c)
df8a954df2aedb9d004e863449be180aad85490fee5856159102c408e8204ecd  mtest_1
df8a954df2aedb9d004e863449be180aad85490fee5856159102c408e8204ecd  mtest_2
df8a954df2aedb9d004e863449be180aad85490fee5856159102c408e8204ecd  mtest_3

$ ./mtest.sh x86_64-w64-mingw32-gcc                                                                                                 
4647ac5ed9c73aa7cb33324d0222b6c45c3ced70b495e92771c323033f9670bb  mtest_1
e43b0fac2bcaa09173c5f5d9b529a9f7ffa2e15e7f67881a8c12226a09058998  mtest_2
d8664c15f4a69de0f605a9c8692db954d47480d281205ef946f0879edb705e73  mtest_3
mtest_1: Patching e8d60fa24e7f0000 to 0000000000000000 at offset 00002880 (virtual address 0000000000404280)
mtest_2: Patching e8d6dbeb997f0000 to 0000000000000000 at offset 00002880 (virtual address 0000000000404280)
mtest_3: Patching e836fb54c67f0000 to 0000000000000000 at offset 00002880 (virtual address 0000000000404280)
51e8cba15304fa7ff52de698b0c9b3ba8a4502df3b099589b56b0e37619e332c  mtest_1
51e8cba15304fa7ff52de698b0c9b3ba8a4502df3b099589b56b0e37619e332c  mtest_2
51e8cba15304fa7ff52de698b0c9b3ba8a4502df3b099589b56b0e37619e332c  mtest_3

laanwj · 2015-10-31T07:48:41Z

Now uses another approach (suggested by @theuni) to make the windows build deterministic, until binutils can be updated.

laanwj · 2015-11-01T13:08:14Z

@theuni I replaced the qt PIDLIST_ABSOLUTE patching with a patch that should work for both old and new mingw.

Should be ready for merge.

laanwj · 2015-11-05T11:29:06Z

Anyone testing this?

fanquake · 2015-11-05T11:32:23Z

Yes. Will post back shortly.

On Thursday, November 5, 2015, Wladimir J. van der Laan <
[email protected]> wrote:

Anyone testing this?

—
Reply to this email directly or view it on GitHub
#6900 (comment).

jonasschnelli · 2015-11-05T11:32:39Z

I'll try this within the next couple of hours.

laanwj · 2015-11-10T14:10:02Z

@jonasschnelli , @fanquake any luck?

laanwj · 2015-11-16T12:28:37Z

Anyone? I'd like to move forward with this, don't think there is anything really holding this back anymore.

jonasschnelli · 2015-11-16T12:49:43Z

I really think this is useful.
But i can't get it running on my Debian 8 jessy machine (see below).
I tried to track this down but it seem after a VirtualBox mkfs issue. Couldn't solve it after investing 1-2h.

$bin/make-base-vm --arch amd64 --suite trusty
-------------- snip -------------------
2015-11-16 13:47:09,510 INFO    : Creating file systems
2015-11-16 13:47:09,666 INFO    : mke2fs 1.42.12 (29-Aug-2014)
2015-11-16 13:47:09,666 INFO    : The file /dev/mapper/loop0p1 does not exist and no size was specified.
2015-11-16 13:47:09,667 INFO    : Cleaning up
2015-11-16 13:47:12,684 ERROR   : Process (['mkfs.ext4', '-F', '/dev/mapper/loop0p1']) returned 1. stdout: , stderr: mke2fs 1.42.12 (29-Aug-2014)
The file /dev/mapper/loop0p1 does not exist and no size was specified.

Traceback (most recent call last):
  File "/usr/local/bin/vmbuilder", line 24, in <module>
    cli.main()
  File "/usr/local/lib/python2.7/dist-packages/VMBuilder/contrib/cli.py", line 228, in main

fanquake · 2015-11-16T12:53:02Z

Have you tried the latest Python vmbuilder? That solved that issue for me,
check in the gitian guide for the updated link.

I haven't had a chance to continue testing after getting that initial issue
solved. I can do tomorrow.

On Monday, November 16, 2015, Jonas Schnelli [email protected]
wrote:

I really think this is useful.
But i can't get it running on my Debian 8 jessy machine (see below).
I tried to track this down but it seem after a VirtualBox mkfs issue.
Couldn't solve it after investing 1-2h.

$bin/make-base-vm --arch amd64 --suite trusty
-------------- snip -------------------
2015-11-16 13:47:09,510 INFO : Creating file systems
2015-11-16 13:47:09,666 INFO : mke2fs 1.42.12 (29-Aug-2014)
2015-11-16 13:47:09,666 INFO : The file /dev/mapper/loop0p1 does not exist and no size was specified.
2015-11-16 13:47:09,667 INFO : Cleaning up
2015-11-16 13:47:12,684 ERROR : Process (['mkfs.ext4', '-F', '/dev/mapper/loop0p1']) returned 1. stdout: , stderr: mke2fs 1.42.12 (29-Aug-2014)
The file /dev/mapper/loop0p1 does not exist and no size was specified.

Traceback (most recent call last):
File "/usr/local/bin/vmbuilder", line 24, in
cli.main()
File "/usr/local/lib/python2.7/dist-packages/VMBuilder/contrib/cli.py", line 228, in main

—
Reply to this email directly or view it on GitHub
#6900 (comment).

jonasschnelli · 2015-11-16T13:32:56Z

@fanquake: Thanks! Damit. I forgot that Debian does not have the python vmbuilder tools over apt. Manually updated and it works now...

Testing gitian building this PR now...

jonasschnelli · 2015-11-16T14:46:18Z

On my debian 8 machine I got the following errors:

Linux:

boost linking problems
- (check the very bottom of the linux.log: ~~https://bitcoin.jonasschnelli.ch/pulls/6900/build-linux.log~~)

MinGW:

---snip---
configure: error: No working boost sleep implementation found.

(check: ~~https://bitcoin.jonasschnelli.ch/pulls/6900/build-win.log~~)

OSX:

works: ~~https://bitcoin.jonasschnelli.ch/pulls/6900/build-osx.log~~

Forgot to add these. Also add a short description for each required library.

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).

laanwj · 2015-11-16T15:41:00Z

Rebased this to master - going to retry my builds

jonasschnelli · 2015-11-16T15:43:51Z

Re-Kicked the builder... log-links above are invalid now.

laanwj · 2015-11-17T07:22:38Z

Getting this now on the windows build, since rebase:

gcc gen_context.o -o gen_context
/usr/bin/x86_64-w64-mingw32-ld: unrecognised emulation mode: elf_x86_64
Supported emulations: i386pep i386pe
collect2: error: ld returned 1 exit status

This is because of:

export COMPILER_PATH=${WRAP_DIR}/${i}

The workaround to set MALLOC_PERTURB_ for linking no longer works. Our collect2 gets invoked for building a native executable too, which obviously fails.
@cfields any idea how to fix this?
I guess moving the export COMPILER_PATH=xxx to ${tuple}-g++/gcc wrappers may work.

laanwj · 2015-11-18T18:05:41Z

Pushed a new commit - all builds including windows should work now.

(when testing, if you used gitian on 0.12 before, make sure that you remove your caches for 0.12, as they will have been built using previous c++ compiler, causing non-determinism and compile/link errors)

jonasschnelli · 2015-11-18T21:14:03Z

All three platforms are working here: https://bitcoin.jonasschnelli.ch/pulls/6900/
Now it would be good if someone would post or compare the assert-files to see if it's really deterministic.

fanquake · 2015-11-19T05:58:00Z

@jonasschnelli Are you building a release, or this pull request on top of master? My signatures don't match with yours currently.

laanwj · 2015-11-19T07:08:49Z

Building commit b082935 with the descriptors of commit b082935 should give:

82a5e6c87137b7a3f18d4230cc22b1d26b95875c436130de123c272defd5d6c9  bitcoin-0.11.99-linux32.tar.gz
f2f81efaeeb16d55dfed2dc6dfa681569cb971b53a8441a3bf083ccb994f82a8  bitcoin-0.11.99-linux64.tar.gz
67c3bc85ece1ad2905a7f801277fbd76d1e7ac653ad2e021cd7fadf1fa6a6307  bitcoin-0.11.99.tar.gz

67c3bc85ece1ad2905a7f801277fbd76d1e7ac653ad2e021cd7fadf1fa6a6307  bitcoin-0.11.99.tar.gz
b2fb5f8b7dcfd9ba1164d13b2aad398fd71b6c7c440b207cf2dfb9302119ff7d  bitcoin-0.11.99-win32-setup-unsigned.exe
5c74be96221c77a7dfce82c0c04d37672e64de06725a9c3a1e372a1e5062addd  bitcoin-0.11.99-win32.zip
75f0403001332f2cec8dc07191eb5c67b97d8dc87a4f41624b974c4a35991ade  bitcoin-0.11.99-win64-setup-unsigned.exe
1592975ac6219793e8c334eb8167c0ccdfa5396e2cf6aa9dd9435ade2cb91b3d  bitcoin-0.11.99-win64.zip
7fd5e22a794a6fa34defe0cd0e82d8f0ad759fba73e190aa5bd202627fa45bc5  bitcoin-0.11.99-win-unsigned.tar.gz

53a9c868e1e2ba862af05f80471f07a57c90b80ccc88e44ec0161bca95c04d75  bitcoin-0.11.99-osx64.tar.gz
b23f22f26c535cc46affd6e6d46f4ef80a33956a93d5e612a0d216537bbfb061  bitcoin-0.11.99-osx-unsigned.dmg
6cf0b9a04f46bca67defff1f9240c10a1e432b7659f3a5a8e231e0292ec8ea4c  bitcoin-0.11.99-osx-unsigned.tar.gz
67c3bc85ece1ad2905a7f801277fbd76d1e7ac653ad2e021cd7fadf1fa6a6307  bitcoin-0.11.99.tar.gz

jonasschnelli · 2015-11-19T07:11:35Z

@fanquake: right. My build script always pulls a PR on top of master. A match would only be possible if you do the same (check the git HEAD~5 log): https://bitcoin.jonasschnelli.ch/pulls/6900/

But i'll try now to build b082935 (to compare with @laanwj 's hashes)

jonasschnelli · 2015-11-19T08:13:04Z

Linux / OSX: match

~~Windows: no match (https://bitcoin.jonasschnelli.ch/pulls/6900/bitcoin-win-0.12-build.assert) ~~
I used

b8affff612d645598a4642dcc4eef7d4974c02d73c31a99ba2faa36425142aca  bitcoin-win-0.12-desc.yml
git:b08293544a207088193de8834bb754f5d212c9bf bitcoin

Any ideas?

laanwj · 2015-11-19T08:22:16Z

~~Which packages differ? Can you upload them?~~
Looking at your assert link, they simply match.

jonasschnelli · 2015-11-19T08:30:31Z

Correction: window build matched. (Compared against the wrong file).

Nice!
Tested ACK.

2cecb24 doc: change suite to trusty in gitian-building.md (Wladimir J. van der Laan) 957c0fd gitian: make windows build deterministic (Wladimir J. van der Laan) 2e31d74 gitian: use trusty for building (Wladimir J. van der Laan) 0b416c6 depends: qt PIDLIST_ABSOLUTE patch (Wladimir J. van der Laan) 9f251b7 devtools: add libraries for bitcoin-qt to symbol check (Wladimir J. van der Laan)

fanquake · 2015-11-19T12:05:05Z

ACK

On Thursday, November 19, 2015, Wladimir J. van der Laan <
[email protected]> wrote:

Merged #6900 #6900.

—
Reply to this email directly or view it on GitHub
#6900 (comment).

laanwj · 2015-11-19T12:28:38Z

Thanks a lot for testing @fanquake @jonasschnelli

theuni · 2015-11-19T17:38:29Z

@laanwj Sorry for missing this while traveling.

For the cache issue, sounds like depends needs to take the output as $(CXX) -v as part of the hash, so that a new compiler invalidates all binaries.

Upstream gitian updates This PR pulls in all gitian-related PRs that have been merged upstream since 0.11.2. The only ones I left out were documentation-only PRs, because we removed `doc/gitian-building.md` at some point. Here are the commits applied here, in the order shown in `git log` (ie. last to first): - bitcoin/bitcoin#7283 - fa42a67 - fa58c76 - bitcoin/bitcoin#8175 - 74c1347 - bitcoin/bitcoin#8167 - 7e7eb27 - ad38204 - b676f38 - bitcoin/bitcoin#7776 - f063863 - bitcoin/bitcoin#7424 - a81c87f ~ we already partly applied - a8ce872 - f3d3eaf ~ we already partly applied - 475813b - ~~cd27bf5~~ X we already applied - bitcoin/bitcoin#7060 - 3b468a0 ~ we removed doc/gitian-building.md - ~~99fda26~~ X we removed doc/gitian-building.md - bitcoin/bitcoin#7251 - fa09562 - bitcoin/bitcoin#6900 - ~~2cecb24~~ X we removed doc/gitian-building.md - 957c0fd - 2e31d74 - ~~0b416c6~~ X we removed QT - 9f251b7 - bitcoin/bitcoin#6854 - 579b863 ~ we already partly applied Part of #540

This workaround was added as part of the switch to gitian building using Ubuntu 14.04 (bitcoin#6900). However, it should no longer be required, as we have switched to Bionic (bitcoin#13171), and that has a far newer version of binutils. binutils patch: https://sourceware.org/bugzilla/show_bug.cgi?id=16192

…escriptor bd3f5a9 build: remove mingw linker workaround from win gitian descriptor (fanquake) Pull request description: This workaround was added as part of the switch to gitian building using Ubuntu 14.04 (#6900). However, it should no longer be required, as we have switched to Bionic (#13171) and that has a far newer version of binutils. Original discussion: #6900 binutils patch: https://sourceware.org/bugzilla/show_bug.cgi?id=16192 ACKs for top commit: MarcoFalke: ACK bd3f5a9 theuni: ACK bd3f5a9 laanwj: ACK bd3f5a9 Tree-SHA512: 01a5789994decf8cdedf7aaa0a449d2100a77e2e6b422d6b9dd5a4ac3e2e0b538c3d43aae4a1c3713614782f3c6b09d8d8bb21c20e86ce3c1734183dedd02d0c

…itian descriptor bd3f5a9 build: remove mingw linker workaround from win gitian descriptor (fanquake) Pull request description: This workaround was added as part of the switch to gitian building using Ubuntu 14.04 (bitcoin#6900). However, it should no longer be required, as we have switched to Bionic (bitcoin#13171) and that has a far newer version of binutils. Original discussion: bitcoin#6900 binutils patch: https://sourceware.org/bugzilla/show_bug.cgi?id=16192 ACKs for top commit: MarcoFalke: ACK bd3f5a9 theuni: ACK bd3f5a9 laanwj: ACK bd3f5a9 Tree-SHA512: 01a5789994decf8cdedf7aaa0a449d2100a77e2e6b422d6b9dd5a4ac3e2e0b538c3d43aae4a1c3713614782f3c6b09d8d8bb21c20e86ce3c1734183dedd02d0c

This workaround was added as part of the switch to gitian building using Ubuntu 14.04 (dashpay#6900). However, it should no longer be required, as we have switched to Bionic (bitcoin#13171), and that has a far newer version of binutils. binutils patch: https://sourceware.org/bugzilla/show_bug.cgi?id=16192

laanwj added the Build system label Oct 29, 2015

laanwj force-pushed the 2015_10_gitian_trusty branch 4 times, most recently from 47a9d6e to 4eb6d24 Compare November 1, 2015 13:07

laanwj mentioned this pull request Nov 2, 2015

gitian: windows and linux/osx source archive don't match #6929

Closed

laanwj added this to the 0.12.0 milestone Nov 2, 2015

laanwj mentioned this pull request Nov 5, 2015

mingw32 depends build fails #6950

Closed

fanquake mentioned this pull request Nov 11, 2015

[gitian] Use latest vm-builder ( 0.12.4+bzr494 ) on Debian #6985

Merged

laanwj force-pushed the 2015_10_gitian_trusty branch from 4eb6d24 to 0340ffb Compare November 16, 2015 15:39

laanwj added 3 commits November 16, 2015 16:39

devtools: add libraries for bitcoin-qt to symbol check

9f251b7

Forgot to add these. Also add a short description for each required library.

depends: qt PIDLIST_ABSOLUTE patch

0b416c6

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).

gitian: use trusty for building

2e31d74

laanwj force-pushed the 2015_10_gitian_trusty branch from b082935 to 2cecb24 Compare November 19, 2015 12:01

laanwj added 2 commits November 19, 2015 13:01

gitian: make windows build deterministic

957c0fd

doc: change suite to trusty in gitian-building.md

2cecb24

laanwj merged commit 2cecb24 into bitcoin:master Nov 19, 2015

jonasschnelli mentioned this pull request Dec 14, 2015

depends cache no longer works within Gitian #7207

Closed

dgenr8 mentioned this pull request Aug 11, 2016

C++11 bitcoinxt/bitcoinxt#148

Closed

str4d mentioned this pull request Oct 15, 2016

Upstream gitian updates zcash/zcash#1541

Merged

fanquake mentioned this pull request Aug 20, 2019

build: remove mingw linker workaround from win gitian descriptor #16667

Merged

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021

gitian: build on ubuntu 14.04 #6900

gitian: build on ubuntu 14.04 #6900

Uh oh!

Conversation

laanwj commented Oct 29, 2015

Windows build is not deterministic

Uh oh!

wtogami commented Oct 29, 2015

Uh oh!

laanwj commented Oct 29, 2015

Uh oh!

theuni commented Oct 30, 2015

Uh oh!

laanwj commented Oct 30, 2015

Uh oh!

laanwj commented Oct 30, 2015

Uh oh!

laanwj commented Oct 30, 2015

Uh oh!

laanwj commented Oct 31, 2015

Uh oh!

laanwj commented Nov 1, 2015

Uh oh!

laanwj commented Nov 5, 2015

Uh oh!

fanquake commented Nov 5, 2015

Uh oh!

jonasschnelli commented Nov 5, 2015

Uh oh!

laanwj commented Nov 10, 2015

Uh oh!

laanwj commented Nov 16, 2015

Uh oh!

jonasschnelli commented Nov 16, 2015

Uh oh!

fanquake commented Nov 16, 2015

Uh oh!

jonasschnelli commented Nov 16, 2015

Uh oh!

jonasschnelli commented Nov 16, 2015

Linux:

MinGW:

OSX:

Uh oh!

laanwj commented Nov 16, 2015

Uh oh!

jonasschnelli commented Nov 16, 2015

Uh oh!

laanwj commented Nov 17, 2015

Uh oh!

laanwj commented Nov 18, 2015

Uh oh!

jonasschnelli commented Nov 18, 2015

Uh oh!

fanquake commented Nov 19, 2015

Uh oh!

laanwj commented Nov 19, 2015

Uh oh!

jonasschnelli commented Nov 19, 2015

Uh oh!

jonasschnelli commented Nov 19, 2015

Uh oh!

laanwj commented Nov 19, 2015

Uh oh!

jonasschnelli commented Nov 19, 2015

Uh oh!

fanquake commented Nov 19, 2015

Uh oh!

laanwj commented Nov 19, 2015

Uh oh!

theuni commented Nov 19, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants