Closed
Bug 1342292
Opened 8 years ago
Closed 6 years ago
error: failed to load source for a dependency on '<any>' when there is empty directory into third_party/rust
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox54 affected)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox54 | --- | affected |
People
(Reporter: m_kato, Unassigned)
References
Details
When there is empty directory into third_party/rust/, I cannot build Gecko due to the following build error.
0:13.98 Elapsed: 0.40s; From ../../dist/idl: Kept 0 existing; Added/updated 1104; Removed 0 files and 0 directories.
0:15.87 force-cargo-library-build
0:16.92 error: failed to load source for a dependency on `parking_lot`
0:16.92
0:16.92 Caused by:
0:16.92 Unable to update registry https://github.com/rust-lang/crates.io-index
0:16.92
0:16.92 Caused by:
0:16.92 failed to update replaced source `registry https://github.com/rust-lang/crates.io-index`
0:16.92
0:16.92 Caused by:
0:16.92 failed to read `C:\Development\hg.mozilla.org\mozilla-inbound\third_party\rust\app_units-0.3.0\Cargo.toml`
0:16.92
0:16.92 Caused by:
0:16.92 隰厄ソス・ョ螢ケ・・ケァ蠕娯螺郢晁シ斐<郢ァ・、郢晢スォ邵コ迹夲スヲ荵昶命邵コ荵晢ス 顔クコ・セ邵コ蟶呻ス鍋クイ・ス(os error 2)
0:16.93 c:/Development/hg.mozilla.org/mozilla-inbound/config/rules.mk:959: recipe for target 'force-cargo-library-build' failed
0:16.93 mozmake.EXE[5]: *** [force-cargo-library-build] Error 101
app_units-0.3.0 and app_units-0.3.0/src are empty, but build system tries to use it.
$ ls -al /c/Development/hg.mozilla.org/mozilla-inbound/third_party/rust/app_units-0.3.0/src
total 4
drwxr-xr-x 2 mkato Administrators 0 Feb 24 10:46 .
drwxr-xr-x 3 mkato Administrators 4096 Feb 24 10:46 ..
Of course, I remove this directory, I can build it well.
Comment 1•8 years ago
|
||
(In reply to Makoto Kato [:m_kato] from comment #0)
> 0:16.92 Caused by:
> 0:16.92 隰厄ソス・ョ螢ケ・・ケァ蠕娯螺郢晁シ斐<郢ァ・、郢晢スォ邵コ迹夲スヲ荵昶命邵コ荵晢ス 顔クコ・セ邵コ蟶呻ス鍋クイ・ス(os
> error 2)
Is the mojibake from your copy/paste, or is it like that on your console? There might be a separate bug to file for that.
Reporter | ||
Comment 2•8 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #1)
> (In reply to Makoto Kato [:m_kato] from comment #0)
> > 0:16.92 Caused by:
> > 0:16.92 隰厄ソス・ョ螢ケ・・ケァ蠕娯螺郢晁シ斐<郢ァ・、郢晢スォ邵コ迹夲スヲ荵昶命邵コ荵晢ス 顔クコ・セ邵コ蟶呻ス鍋クイ・ス(os
> > error 2)
>
> Is the mojibake from your copy/paste, or is it like that on your console?
> There might be a separate bug to file for that.
In command prompt, this corrupted message is shown. (Maybe, error is UTF-8, but console is Shift JIS. This is another bug). error code is 2, so it shows "file not found".
Comment 3•8 years ago
|
||
(In reply to Makoto Kato [:m_kato] from comment #2)
> In command prompt, this corrupted message is shown. (Maybe, error is UTF-8,
> but console is Shift JIS. This is another bug). error code is 2, so it
> shows "file not found".
It would be worth determining whether that's the mach wrapping that causes this, or if cargo displays that on its own. If the latter, you should file a bug against cargo (which might be a rust libstd bug)
Comment 4•8 years ago
|
||
As for the original bug, here's how I finally was able to reproduce:
Checkout a tree before bug 1340838 (at least 2 pushes before, because the tree is busted on the previous push, so up to and including 16f9a685598b).
Create an empty third_party/rust/app_units-0.3.0/src
And then build (shortcut: mach configure; mach build toolkit/library/rust/force-cargo-library-build)
It looks very much like this is purely a cargo vendoring bug, whereby there is:
- an empty $vendor_path/$crate-$version
- a $vendor_path/$crate directory with the right $version
and it decides to pick the first and not try the second. The first probably is there because of some weird issue during the tree update from VCS.
A smaller testcase than doing this with a clone of mozilla-central on the right revision can be done with simple crates with dependencies, like so:
$ cargo new testcase
$ cd testcase
$ echo 'log = "0.3"' >> Cargo.toml
$ cargo build # build once to create Cargo.lock, that cargo vendor wants
$ cargo vendor
Do what cargo vendor says, then
$ mkdir vendor/log-0.3.6
$ cargo build
This last command fails.
Flags: needinfo?(acrichton)
Comment 5•8 years ago
|
||
Thanks for the cc, this is actually a bug in Cargo I believe rather than vendoring itself. Cargo currently assumes that all directories in the vendor dir are valid crate dirs (e.g. those with Cargo.toml), but it looks like that's not the case here!
Were these empty dirs created and/or left around by git? If it's normal operation that creates these then we should probably just ignore empty dirs in Cargo itself.
FWIW I think this is related to these lines in Cargo [1] where we force all directories to have a valid package, but a missing Cargo.toml is an error (e.g. we could just ignore those errors and skip that directory entry)
[1]: https://github.com/rust-lang/cargo/blob/163de44297b052c8c8668f75a51029b6ed8a0416/src/cargo/sources/directory.rs#L84-L86
Flags: needinfo?(acrichton)
Reporter | ||
Comment 6•8 years ago
|
||
If using Windows, when user's current directory is third_party/rust/app_units-0.3.0/src, it isn't removed even if HG tries removing this. (OSX and Linux remove it correctly...)
Comment 7•8 years ago
|
||
Does that end up being a common ocurrence? It'd be a bit of a shame to ignore malformed directories because that may ignore legitimate bugs by accident (causing hard to track down issues), but we could also perhaps just ignore explicitly empty directories (unsure if theres child directories to worry about here)
Comment 9•8 years ago
|
||
I've sent a PR to Cargo (https://github.com/rust-lang/cargo/pull/3899) to update its behavior
Updated•7 years ago
|
Product: Core → Firefox Build System
Comment 10•6 years ago
|
||
It looks like this fix shipped in cargo a while ago: cargo 0.20 which shipped with Rust 1.19.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•