macOS WPT taskcluster job is busted

[jdm]

Every PR since #22459 has failed when running this task:

+ ./mach test-wpt --release --binary-arg=--multiprocess --processes 4 --log-raw test-wpt-mp.log --log-errorsummary wpt-mp-errorsummary.log eventsource

with errors like:

  ▶ CRASH [expected OK] /eventsource/dedicated-worker/eventsource-close.htm
  │ 
  │ dyld: Library not loaded: /Users/worker/homebrew/opt/harfbuzz/lib/libharfbuzz.0.dylib
  │   Referenced from: /Users/worker/tasks/task_1545209316/repo/target/release/servo
  └   Reason: Incompatible library version: servo requires version 20201.0.0 or later, but libharfbuzz.0.dylib provides version 20102.0.0

[jdm]

I am unclear why this does not appear on #22459 itself.

[SimonSapin]

Looks like the libharfbuzz version Servo was compiled with differs from the one available when this failure occurs. We only have two workers, and they both have Harfbuzz in a persistent Homebrew install at /Users/worker/homebrew. This likely happens when the build task and run task are on different workers, which is non-deterministic. Running /Users/worker/homebrew/bin/brew update harfbuzz on both workers might solve this immediate issue, but something like it might happen again. Can we pin exact versions in Homebrew? Are older versions available at all?

[SimonSapin]

Running /Users/worker/homebrew/bin/brew update harfbuzz on both workers

After su - worker, not as root.

[jdm]

brew pin harfbuzz should pin the currently installed version.

[jdm]

I have manually updated the older copy, so this should no longer prevent merging anything.

[jdm]

If we're not explicitly upgrading homebrew packages on workers as part of CI, then the only time this should affect us is when provisioning new builders, which will end up installing the latest package version.

[SimonSapin]

Another possible case is if we add a new dependency. It’ll be installed on each worker the first time there’s a build job, which may vary across builder. It is unlikely but possible that a new version is published in that window.

But really, shouldn’t we be statically linking harfbuzz and (some) other dependencies? Then this issue wouldn’t exist in the first place.

[jdm]

Yeah, we should probably be setting the HARFBUZZ_SYS_NO_PKG_CONFIG variable so we don't short-circuit at https://github.com/servo/rust-harfbuzz/blob/master/harfbuzz-sys/build.rs#L10-L14.

[SimonSapin]

Could we instead use pkg_config::Config::statik to attempt static linking with a system-provided Harfbuzz rather than always recompile it?