Update macOS toolchain for Firefox 78 ESR

We need to go over our macOS toolchain and update it wherever we think it's needed for Firefox 78 ESR.

• #33410 (closed)
• #40003 (closed)
• #40019 (closed)

Trac:
Parent Ticket: legacy/trac#34227 (moved)

added component::applications/tor browser in Legacy / Trac ff78-esr in Legacy / Trac gitlab-tb-tor-browser-build in Legacy / Trac owner::tbb-team in Legacy / Trac parent::34227 in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-rbm in Legacy / Trac type::task in Legacy / Trac labels

One thing we need to update is cc-tools, see: https://searchfox.org/mozilla-beta/source/taskcluster/ci/fetch/toolchains.yml#295.

Trac:
Parent: legacy/trac#34228 (moved) to legacy/trac#34227 (moved)

Add magic gitlab keyword.

Trac:
Keywords: N/A deleted, gitlab-tb-tor-browser-build added

mentioned in issue legacy/trac#34227 (moved)

moved from legacy/trac#34229 (moved)

mentioned in issue #34227 (closed)

changed the description

added Task label and removed 1 deleted label

removed 1 deleted label

I made some progress over the weekend. Everything seems to be building with the updated toolchain "just" XUL barfs when trying to link it:

62:16.26 Undefined symbols for architecture x86_64:
62:16.26   "___isOSVersionAtLeast", referenced from:
62:16.27       __Z19GetDefaultBundleURLRK12nsTSubstringIcEPPK7__CFURL in Unified_mm_uriloader_exthandler0.o
62:16.28       __ZL18GetPermissionStateP8NSStringRt in Unified_mm_widget_cocoa0.o
62:16.28       __ZN12nsCocoaUtils31GetScreenCapturePermissionStateERt in Unified_mm_widget_cocoa0.o
62:16.28       __ZN12nsCocoaUtils24RequestCapturePermissionEP8NSStringR6RefPtrIN7mozilla3dom7PromiseEERNS3_13StaticAutoPtrI8nsTArrayIS6_EEEU13block_pointerFvaE in Unified_mm_widget_cocoa0.o
62:16.45 ld: symbol(s) not found for architecture x86_64
62:16.49 clang-9: error: linker command failed with exit code 1 (use -v to see invocation)

@mcs, @brade: when you compiled @acat's branches (I used 33533+10) you compiled natively, right? Or did you use a cross-compilation setup similar to ours/Mozilla's?

@mcs, @brade: when you compiled @acat's branches (I used 33533+10) you compiled natively, right? Or did you use a cross-compilation setup similar to ours/Mozilla's?

We have not tried to cross compile a post-ESR68 branch. We have been building natively using the compiler and tools from Xcode 10.3 (which includes Apple's llvm/clang 10.0.1 and the macOS 10.14 SDK). I assume the error you encountered is caused by the following statement in uriloader/exthandler/mac/nsOSHelperAppService.mm:

if (@available(macOS 10.10, *)) {

Use of @available in Objective-C code is fairly new. I am probably stating the obvious, but I guess there is some other library we need to link with to avoid the undefined symbol (but it also seems like the toolchain should do that automatically). Maybe we need a newer macOS SDK?

Mark Smith:

Mark Smith commented:

@mcs, @brade: when you compiled @acat's branches (I used 33533+10) you compiled natively, right? Or did you use a cross-compilation setup similar to ours/Mozilla's?

We have not tried to cross compile a post-ESR68 branch. We have been building natively using the compiler and tools from Xcode 10.3 (which includes Apple's llvm/clang 10.0.1 and the macOS 10.14 SDK). I assume the error you encountered is caused by the following statement in uriloader/exthandler/mac/nsOSHelperAppService.mm:

if (@available(macOS 10.10, *)) {

Use of @available in Objective-C code is fairly new. I am probably stating the obvious, but I guess there is some other library we need to link with to avoid the undefined symbol (but it also seems like the toolchain should do that automatically).

Yep, if we built it. :) Turns out we don't cross-compile the compiler-rt library for macOS (the Windows part gets cross-compiled in the mingw-w64-clang project). If I just copy over the lib from Mozilla (which we might want to do to get our nightly builds going assp) then things are working seamlessly. So, this is essentially #29041 biting us.

added 1 deleted label

changed the description

added Doing label

assigned to @gk

marked the checklist item #33410 (closed) as completed