I'm using MozillaBuild 3.3, I've rerun ./mach vcs-setup --update-only, I've clobbered, and I have current tip (cb56699431a0) checked out.

After bypassing the isssue reported in bug 1585258 by adding /Users/jwatt/.cargo/bin to my PATH and invoking cargo install cbindgen --force, I re-ran ./mach build. Now I get a new error:

0:09.73 checking for dump_syms... no
0:09.73 ERROR: Cannot find dump_syms. Please run `mach bootstrap`, `cargo install dump_syms`,
0:09.73 ensure that `dump_syms` is on your PATH, or point at an executable with `DUMP_SYMS`.
0:09.82 *** Fix above errors and then restart with\
0:09.82 "./mach build"
0:09.82 mozmake.EXE: *** [client.mk;115: configure] Error 1

Unfortunately I don't seem to be able to install dump_syms:

$ cargo install dump_syms
Updating crates.io index
error: could not find `dump_syms` in registry `https://github.com/rust-lang/crates.io-index`

(Running rustup.exe update doesn't help.)

I'm seeing this issue, too. Using MozBuild as well.

Per input from Calixte (thanks!), a temporary workaround is to build the crate manually:

git clone https://github.com/mozilla/dump_syms && cd dump_syms && cargo build --release

Then add the release/dumpsyms directory from wherever you cloned the repo into your $PATH.

./mach artifact toolchain --from-build win64-dump-syms should work too.

./mach bootstrap will fetch an up-to-date version of dump_syms within your .mozbuild folder and the configure script should detect it automatically. Unfortunately we couldn't push it to crates.io yet because of some changes we've added to the dependencies which haven't been merged upstream yet.

(In reply to Gabriele Svelto [:gsvelto] from comment #4)

./mach bootstrap will fetch an up-to-date version of dump_syms

./mach bootstrap is broken right now (Bug 1614146). I'll depend this bug on that one. We should probably (minimally) fix the inaccurate error message suggesting cargo install dump_syms until that crate is pushed.

Should this be required for non-automation builds?

Actually, probably not.

The requirement was introduced for consistency since the previous version was built in tree and was thus always present in local builds. It can be made optional there though, I have no issue with that.

I don't know why I didn't see this on review, but the check for dump_syms could, on top of being optional, be much simpler, and more in line with other checks. On the latter, one thing that goes wrong currently is that if we give a path via an environment variable, it's never actually tested during configure, and not resolved to a fully qualified path either.

https://hg.mozilla.org/mozilla-central/rev/8f77571d5a95

This keeps failing on central:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=windows%2C2012%2Cx64%2Cdebug%2Cstatic-analysis-autotest-win64-st-autotest%2Fdebug%2C%28sa%29&revision=7a5cb26a2d518e9cfaf512ba9a06239b573d7f0e

log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290707449&repo=mozilla-central&lineNumber=689

https://hg.mozilla.org/mozilla-central/rev/4906fd5a8dd8