Switch rbm VMs for Windows to those used for our macOS cross-builds

[gk]

We should switch the rbm VMs for Windows to the ones used for our macOS cross-builds. This should simplify our setup and would provide us with better build tools.

[gk]

Actually we should switch to the ones we use for cross-compiling for macOS.

[boklm]

The first issue when switching to jessie for the Windows builds is a build error in binutils:

In file included from as.h:95:0,
                 from subsegs.c:25:
subsegs.c: In function 'subseg_change':
../bfd/bfd.h:304:75: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
 #define bfd_set_section_userdata(bfd, ptr, val) (((ptr)->userdata = (val)),TRUE)
                                                                           ^
subsegs.c:70:7: note: in expansion of macro 'bfd_set_section_userdata'
       bfd_set_section_userdata (stdoutput, seg, seginfo);
       ^
subsegs.c: In function 'subseg_get':
../bfd/bfd.h:304:75: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
 #define bfd_set_section_userdata(bfd, ptr, val) (((ptr)->userdata = (val)),TRUE)
                                                                           ^
subsegs.c:172:7: note: in expansion of macro 'bfd_set_section_userdata'
       bfd_set_section_userdata (stdoutput, secptr, seginfo);
       ^
In file included from as.h:95:0,
                 from write.c:25:
write.c: In function 'record_alignment':
../bfd/bfd.h:303:83: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
 #define bfd_set_section_alignment(bfd, ptr, val) (((ptr)->alignment_power = (val)),TRUE)
                                                                                   ^
write.c:366:5: note: in expansion of macro 'bfd_set_section_alignment'
     bfd_set_section_alignment (stdoutput, seg, align);
     ^
cc1: all warnings being treated as errors

This issue is fixed by taking commit 27b829ee701e29804216b3803fbaeb629be27491 from binutils:
​https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=27b829ee701e29804216b3803fbaeb629be27491

[gk]

FWIW: my plan is to upgrade both binutils and GCC for the switch to ESR 60, so if some of that helps with this bug, feel free to do changes during work on this bug that would benefit #16472 and #20301/#20302. There's a trade-off here, though: this bug is much more urgent as Canonical might plug the cable for Precise, which is EOL for a while now, any day. So, we should not get delayed here by issues popping up when solving #16472 and #20301.

[boklm]

I have been thinking about updating binutils to fix the issue, but it seems the fix is simple enough to do that separately.

I have now been able to build the Windows 32 and 64 versions using Debian Jessie with the patch in branch bug_18691_v2:
​https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_18691_v2&id=218dc2a5bffdb2bcadb4552659baf82e0043469c

The main changes included in this patch are:

• adding a patch to fix the binutils build
• updating the libfaketime path
• installing the wine package from the main jessie repository instead of the ubuntu ppa repository, so we are moving from wine 1.7.18 to 1.6.2. We could use version 1.8.7 from jessie-backports but it seems version 1.6.2 is enough.
• using wine winepath, wine msiexec and wine wineboot instead of winepath, msiexec and wineboot as they do not seem to work with this version of the wine package.

I checked that both 32 and 64 bits builds are running correctly. However I did not check yet that the build is still reproducible.

[boklm]

Replying to boklm:

However I did not check yet that the build is still reproducible.

I have now checked that with a build done on 2 machines.

[cypherpunks]

After New Year's disclosures, there is a time to update everything:
OSes are still patching holes (Stretch looks better),
binutils 2.30 will be ready in Jan (#16472 is needed for win64),
GCC 7.3 should include new mitigations (GCC 6.4 could be a first step in upgrade, GCC 5.x is no longer supported),
otherwise LGTM.

[gk]

Replying to boklm:

Replying to boklm:

However I did not check yet that the build is still reproducible.

I have now checked that with a build done on 2 machines.

Nice. Looks good to me. I think I'll merge that once we are preparing the alpha and there is a maint-7.5 branch in tor-browser-build.

[gk]

Okay, merged to master now (commit 218dc2a5bffdb2bcadb4552659baf82e0043469c), thanks.