Closed
Bug 1377157
Opened 8 years ago
Closed 8 years ago
Rust 1.19 hits error: could not exec the linker `link.exe`
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(firefox56 fixed)
RESOLVED
FIXED
mozilla56
| Tracking | Status | |
|---|---|---|
| firefox56 | --- | fixed |
People
(Reporter: away, Assigned: froydnj)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
2.60 KB,
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
Originally https://github.com/rust-lang/rust/issues/42607 but after some debugging it seems the fix should be on the gecko side. See https://github.com/rust-lang/rust/issues/42607#issuecomment-311825461
| Assignee | ||
Updated•8 years ago
|
Assignee: nobody → nfroyd
| Assignee | ||
Comment 1•8 years ago
|
||
Stable Rust currently has logic similar to the following for finding the
linker on Windows:
if VCINSTALLDIR in os.env:
search for things in PATH
if found, return, otherwise fallthrough
look for MSVC installations of various kinds
For our current MozillaBuild setup where we clear out PATH prior to
invoking Cargo, this works: even though VCINSTALLDIR is set and we
(unsuccessfully) search through an empty PATH, we'll still fallback to
looking for MSVC installations.
Beta Rust has altered this search strategy:
if VCINSTALLDIR in os.env:
search for things in PATH
return the result of the search, regardless of success
look for MSVC installations of various kinds
Note that in the above logic, if VCINSTALLDIR is set, we are only going
to try looking in PATH for an appropriate linker. Since PATH is empty
in our current MozillaBuild setup, beta Rust will therefore fail to find
the correct linker. This failure causes numerous problems.
Since Firefox is already trying to "clean" the environment that Cargo is
invoked in, we should work a little bit harder by unsetting VCINSTALLDIR
entirely, and simply force Rust to search for known MSVC installations.
Making this change makes stable and beta Rust behave identically.
(We don't have to worry about this distinction in automation, because
the "cleaning" code is only activated when we detect a MozillaBuild
shell.)
It's not clear to me whether we should have been using -u for the other
environment variables we're cleaning here, but one step at a time, I
suppose...
Attachment #8882273 -
Flags: review?(ted)
| Assignee | ||
Updated•8 years ago
|
Blocks: stylo-tooling
Comment 2•8 years ago
|
||
Comment on attachment 8882273 [details] [diff] [review]
remove VCINSTALLDIR from cargo's environment when running in MozillaBuild
Review of attachment 8882273 [details] [diff] [review]:
-----------------------------------------------------------------
I wish this whole situation was better, but making things work is better than having them not work.
Attachment #8882273 -
Flags: review?(ted) → review+
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/50130098edb3
remove VCINSTALLDIR from cargo's environment when running in MozillaBuild; r=ted.mielczarek
Comment 4•8 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•