This doesn't work yet. Fails at:

ERROR at //build/config/BUILDCONFIG.gn:239:3: Assertion failed.
  assert(target_os == host_os, "Win cross-compiles only work on win hosts.")
  ^-----
Win cross-compiles only work on win hosts.

This is mainly to get the git-gpg-wrapper fix.

boklm authored Aug 08, 2017 and Georg Koppen committed Aug 09, 2017

Thanks to dcf for finding the cause of the problem.

Changelog update, version bumps, and config.yml update

This reverts commit e8178d13.

That's properly fixed in NoScript >= 5.0.7.1, thus removing our
workaround.

This fixes bug 22067.

We bump our GCC compiler to 5.4.0 as this fixes some bugs
in previous versions. It allows us in particular to build
debug builds for Windows with mingw-w64.

Found by boklm.

Whitelist about:tor so that NoScript does not block its JavaScript.

David Fifield authored Jul 05, 2017 and Georg Koppen committed Jul 14, 2017

I had to apply two tricks to get a reproducible snowflake-client.

The first is to use faketime to eliminate some timestamps. There were 11
variable timestamps in the file. Through experimentation, I found that
10 of them were dependent on the Go runtime (recompiling Go caused them
to change) and 1 was dependent on snowflake-client itself (recompiling
snowflake-client with the same runtime changed only that 1 timestamp).
The underlying issue has to do with clang 3.8.0 on Darwin embedding
timestamps, unsolved in the Go issue tracker as of 13 days ago.
https://github.com/golang/go/issues/9206#issuecomment-310476743

The second is a sed command to clobber embedded paths of the form
/tmp/go-buildXXXXXXXXX and /tmp/go-link-XXXXXXXXX. Their presence is
caused by some combination of Clang and Darwin, and there is as yet no
known workaround upstream.

David Fifield authored Jul 05, 2017 and Georg Koppen committed Jul 10, 2017

Object files from elsewhere under out/ should never have been included,
because they are not part of webrtc itself, but rather side-effect build
artifacts like gn. Including those extraneous .o files was mostly
harmless (except for library size), because on linux they happened to be
the same architecture as the webrtc.o files. However it won't work for
the mac build (because libwebrtc-magic.a would include a mix of linux
ELF and mac Mach-O objects). Additionally, build_time.o, part of the gn
build, embeds a timestamp with month resolution, causing a failure of
reproducibility, as found at https://bugs.torproject.org/22832.

This is apparently an unsolved bug having to do with current versions of
Clang on Darwin.

There were 11 variable timestamps in the file. Through experimentation,
I found that 10 of them were dependent on the Go runtime (recompiling Go
caused them to change) and 1 was dependent on snowflake-client itself
(recompiling snowflake-client with the same runtime changed only that 1
timestamp).

The underlying issue has to do with clang 3.8.0 on Darwin embedding
timestamps, unsolved in the Go issue tracker as of 6 days ago. (That
version of clang also embeds variable absolute paths, which is not
handled by this commit.)
https://github.com/golang/go/issues/9206#issuecomment-310476743

This sets timestamps inside the archive to zero. The variable timestamps
were eventually finding their way inside of snowflake-client.

Currently the windows code doesn't work and crashes during the build.
Remove it until it's working so we can run a start-to-finish build
(including windows sans snowflake) in this branch.