Move our macOS builds to Debian Stretch

In #29307 (moved) we switched the host of our Windows builds from Debian Jessie to Stretch. We should do the same for macOS builds. We should have this done for Tor Browser 9, I think.

Trac:
Parent Ticket: #30323 (moved)
Child Ticket(s): #30536 (moved)

added GeorgKoppen201905 TorBrowserTeam201905R component::applications/tor browser ff68-esr owner::tbb-team parent::30323 priority::medium resolution::fixed severity::normal sponsor::44-can status::closed tbb-rbm type::defect labels

Trac:
Parent: N/A to #30323 (moved)
Description: In #29307 (moved) we switched the host of our Windows builds from Debian Jessie to Stretch. We should do the same for macOS builds. We should have this done for Tor Browser 9 I think

to

In #29307 (moved) we switched the host of our Windows builds from Debian Jessie to Stretch. We should do the same for macOS builds. We should have this done for Tor Browser 9, I think.

Everything seems to compile fine (with similar small changes as those for Windows). However, snowflake is failing now:

 0.44 host link: "/var/tmp/dist/macosx-toolchain/clang/bin/clang++" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" "-Wl,-pagezero_size,4000000" "-o" "/tmp/go-build136535071/b001/exe/a.out" "-Qunused-arguments" "-Wl,--compress-debug-sections=zlib-gnu" "/var/tmp/go-link.tmpdir/go.o" "/var/tmp/go-link.tmpdir/000000.o" "/var/tmp/go-link.tmpdir/000001.o" "/var/tmp/go-link.tmpdir/000002.o" "/var/tmp/go-link.tmpdir/000003.o" "/var/tmp/go-link.tmpdir/000004.o" "/var/tmp/go-link.tmpdir/000005.o" "/var/tmp/go-link.tmpdir/000006.o" "/var/tmp/go-link.tmpdir/000007.o" "/var/tmp/go-link.tmpdir/000008.o" "/var/tmp/go-link.tmpdir/000009.o" "/var/tmp/go-link.tmpdir/000010.o" "/var/tmp/go-link.tmpdir/000011.o" "/var/tmp/go-link.tmpdir/000012.o" "/var/tmp/go-link.tmpdir/000013.o" "/var/tmp/go-link.tmpdir/000014.o" "/var/tmp/go-link.tmpdir/000015.o" "/var/tmp/go-link.tmpdir/000016.o" "/var/tmp/go-link.tmpdir/000017.o" "/var/tmp/go-link.tmpdir/000018.o" "/var/tmp/go-link.tmpdir/000019.o" "/var/tmp/go-link.tmpdir/000020.o" "/var/tmp/go-link.tmpdir/000021.o" "/var/tmp/go-link.tmpdir/000022.o" "/var/tmp/go-link.tmpdir/000023.o" "/var/tmp/go-link.tmpdir/000024.o" "/var/tmp/go-link.tmpdir/000025.o" "/var/tmp/go-link.tmpdir/000026.o" "/var/tmp/go-link.tmpdir/000027.o" "-target" "x86_64-apple-darwin11" "-B" "/var/tmp/dist/macosx-toolchain/cctools/bin" "-isysroot" "/var/tmp/dist/macosx-toolchain/SDK/" "-stdlib=libc++" "-mmacosx-version-min=10.7" "-target" "x86_64-apple-darwin11" "-B" "/var/tmp/dist/macosx-toolchain/cctools/bin" "-isysroot" "/var/tmp/dist/macosx-toolchain/SDK/" "-stdlib=libc++" "-mmacosx-version-min=10.7" "-L/var/tmp/dist/gopath/src/github.com/keroserene/go-webrtc/lib" "-L/var/tmp/dist/gopath/src/github.com/keroserene/go-webrtc/lib" "-lwebrtc-darwin-amd64-magic" "-framework" "AppKit" "-framework" "CoreAudio" "-framework" "AudioToolbox" "-target" "x86_64-apple-darwin11" "-B" "/var/tmp/dist/macosx-toolchain/cctools/bin" "-isysroot" "/var/tmp/dist/macosx-toolchain/SDK/" "-stdlib=libc++" "-mmacosx-version-min=10.7" "-lpthread" "-target" "x86_64-apple-darwin11" "-B" "/var/tmp/dist/macosx-toolchain/cctools/bin" "-isysroot" "/var/tmp/dist/macosx-toolchain/SDK/" "-stdlib=libc++" "-mmacosx-version-min=10.7" "-framework" "CoreFoundation" "-framework" "Security" "-target" "x86_64-apple-darwin11" "-B" "/var/tmp/dist/macosx-toolchain/cctools/bin" "-isysroot" "/var/tmp/dist/macosx-toolchain/SDK/" "-stdlib=libc++" "-mmacosx-version-min=10.7" "-nopie"
/var/tmp/dist/go/pkg/tool/linux_amd64/link: running /var/tmp/dist/macosx-toolchain/clang/bin/clang++ failed: exit status 1
ld: unknown option: --compress-debug-sections=zlib-gnu
clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)

Yes, -Wl,--compress-debug-sections=zlib-gnu was not an issue with Jessie as there binutils 2.25 got shipped, but that linker option got added to 2.26. Stretch ships with binutils 2.28.

Trac:
Cc: N/A to dcf, cohosh

It's a bit weird, though, that we are seeing ld: unknown option: --compress-debug-sections=zlib-gnu in the error output. The problematic linker flag is there in the first place, it seems, because ld is supporting it now (and assuming that's indeed the linker we use). But suddenly it claims to not know it. Hrm.

ELF targets only ;)

Replying to cypherpunks:

ELF targets only ;)

Yes. So, you mean the flag get set without taking the target into account and then the linker for the target complains? Makes sense. https://github.com/golang/go/issues/27110 and linkerFlagSupported might be relevant here.

That's fixed in go's 1.12 series. Thus, if nothing speaks against it, we could just switch to it to solve this issue.

Alright bug_30491 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_30491&id=cfa06e43015e845c4350b8019c465860f655e1b9) has the fix for this issue. The commit is on top of the one for #30536 (moved). Everything is building fine and the bundles are still matching when built on different machines.

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201905 deleted, GeorgKoppen201905, TorBrowserTeam201905R added

The patch looks good to me. I'm waiting for #30536 (moved) to be merged first before merging this one.

Replying to boklm:

The patch looks good to me. I'm waiting for #30536 (moved) to be merged first before merging this one.

Done and done (the latter got merged to master with commit 734f6d1d8cf70fafaafad687513665477095f2fa)

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Adding Sponsor 44 to ESR68 tickets

Trac:
Sponsor: N/A to Sponsor44-can

closed

mentioned in issue #30492 (moved)

mentioned in issue #30323 (moved)

mentioned in issue #30536 (moved)

moved to tpo/applications/tor-browser#30491 (closed)