Closed
Bug 1377157
Opened 7 years ago
Closed 7 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•7 years ago
|
Assignee: nobody → nfroyd
Assignee | ||
Comment 1•7 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•7 years ago
|
Blocks: stylo-tooling
Comment 2•7 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•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/50130098edb3
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•