Opened 6 weeks ago

Closed 4 weeks ago

#30491 closed defect (fixed)

Move our macOS builds to Debian Stretch

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, ff68-esr, TorBrowserTeam201905R, GeorgKoppen201905
Cc: dcf, cohosh Actual Points:
Parent ID: #30323 Points:
Reviewer: Sponsor:

Description (last modified by gk)

In #29307 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.

Child Tickets

#30536closedtbb-teamUpdate go to 1.12.5Applications/Tor Browser

Change History (9)

comment:1 Changed 6 weeks ago by gk

Description: modified (diff)
Parent ID: #30323

comment:2 Changed 5 weeks ago by gk

Cc: dcf cohosh added

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/" "-L/var/tmp/dist/gopath/src/" "-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.

comment:3 Changed 5 weeks ago by gk

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.

comment:4 Changed 5 weeks ago by cypherpunks

ELF targets only ;)

comment:5 in reply to:  4 Changed 5 weeks ago by gk

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. and linkerFlagSupported might be relevant here.

comment:6 Changed 5 weeks ago by gk

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.

comment:7 Changed 5 weeks ago by gk

Keywords: TorBrowserTeam201905R GeorgKoppen201905 added; TorBrowserTeam201905 removed
Status: newneeds_review

Alright bug_30491 ( has the fix for this issue. The commit is on top of the one for #30536. Everything is building fine and the bundles are still matching when built on different machines.

comment:8 Changed 5 weeks ago by boklm

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

comment:9 in reply to:  8 Changed 4 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

Replying to boklm:

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

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

Note: See TracTickets for help on using tickets.