rustc can't find dependencies when building in a VirtualBox shared drive on a Windows VM

[oconnor663]

Similar to this old issue: rust-lang/rust#21771

I have this main.rs:

extern crate libc;
fn main() {}

And this Cargo.toml:

[package]
name = "hello_world"
version = "0.1.0"
[dependencies]
libc = "*"

cargo build works fine on Linux. But on Windows, I get an error like this:

   Compiling libc v0.2.15
   Compiling hello_world v0.1.0 (file:///E:/hello_world)
src\main.rs:1:1: 1:19 error: use of unstable library feature 'libc': use `libc`
from crates.io (see issue #27783)
src\main.rs:1 extern crate libc;
              ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: Could not compile `hello_world`.

It looks like it's building libc from crates.io, but it's not linking against it or something? I can see a similar error on Linux if I remove the dependencies section, from Cargo.toml, which makes sense to me.

When I try different version with rustup, I see the same thing on 1.0.9, 1.0.10, and nightly.

UPDATE: I'm running all of this in a Windows 7 Virtualbox VM (Linux host), inside a shared drive. But when I try in a regular folder under C:\\, the problem goes away! Something related to shared drives?

[alexcrichton]

Interesting! Could you gist the full output of cargo build -v?

[oconnor663]

E:\hello_world>cargo build -v
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\'
       Fresh libc v0.2.15
   Compiling hello_world v0.1.0 (file:///E:/hello_world)
     Running `rustc src\main.rs --crate-name hello_world --crate-type bin -g --o
ut-dir E:\hello_world\target\debug --emit=dep-info,link -L dependency=E:\hello_w
orld\target\debug -L dependency=E:\hello_world\target\debug\deps --extern libc=E
:\hello_world\target\debug\deps\liblibc-2fef79e23dc08cc8.rlib`
src\main.rs:1:1: 1:19 error: use of unstable library feature 'libc': use `libc`
from crates.io (see issue #27783)
src\main.rs:1 extern crate libc;
              ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: Could not compile `hello_world`.

Caused by:
  Process didn't exit successfully: `rustc src\main.rs --crate-name hello_world
--crate-type bin -g --out-dir E:\hello_world\target\debug --emit=dep-info,link -
L dependency=E:\hello_world\target\debug -L dependency=E:\hello_world\target\deb
ug\deps --extern libc=E:\hello_world\target\debug\deps\liblibc-2fef79e23dc08cc8.
rlib` (exit code: 101)

[oconnor663]

Ah, the same thing seems to apply to another problem I've run into, this time with lazy_static instead of libc. If I substitute lazy_static into the exact same example above, I get a compiler panic that only repros when I build in the shared drive on Windows:

E:\hello_world>cargo run -v
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\'
       Fresh lazy_static v0.2.1
   Compiling hello_world v0.1.0 (file:///E:/hello_world)
     Running `rustc src\main.rs --crate-name hello_world --crate-type bin -g --o
ut-dir E:\hello_world\target\debug --emit=dep-info,link -L dependency=E:\hello_w
orld\target\debug -L dependency=E:\hello_world\target\debug\deps --extern lazy_s
tatic=E:\hello_world\target\debug\deps\liblazy_static-c4d0c6f844c89335.rlib`
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/m
aster/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error {
 repr: Os { code: 1, message: "Incorrect function." } }', ../src/libcore\result.
rs:785
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: Could not compile `hello_world`.

Caused by:
  Process didn't exit successfully: `rustc src\main.rs --crate-name hello_world
--crate-type bin -g --out-dir E:\hello_world\target\debug --emit=dep-info,link -
L dependency=E:\hello_world\target\debug -L dependency=E:\hello_world\target\deb
ug\deps --extern lazy_static=E:\hello_world\target\debug\deps\liblazy_static-c4d
0c6f844c89335.rlib` (exit code: 101)

Looks totally different, but under the circumstances maybe it's related?

[alexcrichton]

Hm that "could not canonicalize" message seems fishy, which seems to be coming from rustup, I wonder if the bug is perhaps there? If you set PATH to include rustc directly without going through rustup, does it work?

[alexcrichton]

cc @brson, fishy messages from rustup

[oconnor663]

If I did this right, looks like it's unrelated to the path warnings?

E:\hello_world>C:\Users\IEUser\.multirust\toolchains\stable-i686-pc-windows-gnu\
bin\rustc.exe src\main.rs --crate-name hello_world --crate-type bin -g --out-dir
 E:\hello_world\target\debug --emit=dep-info,link -L dependency=E:\hello_world\t
arget\debug -L dependency=E:\hello_world\target\debug\deps --extern lazy_static=
E:\hello_world\target\debug\deps\liblazy_static-c4d0c6f844c89335.rlib
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/m
aster/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error {
 repr: Os { code: 1, message: "Incorrect function." } }', ../src/libcore\result.
rs:785
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Edit: Same for the libc error:

E:\hello_world>C:\Users\IEUser\.multirust\toolchains\stable-i686-pc-windows-gnu\
bin\rustc.exe src\main.rs --crate-name hello_world --crate-type bin -g --out-dir
 E:\hello_world\target\debug --emit=dep-info,link -L dependency=E:\hello_world\t
arget\debug -L dependency=E:\hello_world\target\debug\deps --extern libc=E:\hell
o_world\target\debug\deps\liblibc-2fef79e23dc08cc8.rlib
src\main.rs:1:1: 1:19 error: use of unstable library feature 'libc': use `libc`
from crates.io (see issue #27783)
src\main.rs:1 extern crate libc;
              ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error

[alexcrichton]

Hm, can you try setting RUST_LOG=debug and rerun the compiler?

[oconnor663]

@alexcrichton here it is as a gist: https://gist.github.com/oconnor663/8ccd5ea845f2f196645465f5661a623f. Looks like this is the relevant bit:

INFO:rustc_metadata::loader: lib candidate: E:\hello_world\target\debug\deps\liblibc-1bd8847afb79f283.rlib
INFO:rustc_metadata::loader: lib candidate: E:\hello_world\target\debug\deps\liblibc-32002f82878be1c7.rlib
INFO:rustc_metadata::loader: lib candidate: E:\hello_world\target\debug\deps\liblibc-2fef79e23dc08cc8.rlib
INFO:rustc_metadata::loader: lib candidate: C:\Users\IEUser\.multirust\toolchains\stable-i686-pc-windows-gnu\lib\rustlib\i686-pc-windows-gnu\lib\liblibc-e8edd0fd.rlib
INFO:rustc_metadata::loader: rlib reading metadata from: \\?\C:\Users\IEUser\.multirust\toolchains\stable-i686-pc-windows-gnu\lib\rustlib\i686-pc-windows-gnu\lib\liblibc-e8edd0fd.rlib
INFO:rustc_metadata::loader: reading "liblibc-e8edd0fd.rlib" => Duration { secs: 0, nanos: 140520 }

[oconnor663]

More about dependencies other than libc: I tried depending on log instead of lazy_static. Both produce the same panic. Here's the RUST_LOG==debug gist from that one: https://gist.github.com/oconnor663/d483c9ea3a83f389a937e025b8edcd00

Maybe the picture is something like: rustc refuses to select library locations inside of E:\ (my VirtualBox shared drive). Most dependencies lead to this panic as a result, but libc falls back to the installed version in C:\ and gives an unstable feature error. In all cases, copying the entire project to somewhere under C:\ fixes everything.

[alexcrichton]

Hm, can you try running this program?

fn main() {
    println!("{:?}", fs::canonicalize(r"E:\hello_world\target\debug\deps"));
}

My suspicion is that the function is failing so the compiler is ignoring those candidates, but I may be wrong.

[oconnor663]

Here's what I get:

E:\hello_world>cargo run
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\'
   Compiling scratch v0.1.0 (file:///E:/hello_world)
     Running `target\debug\scratch.exe`
Err(Error { repr: Os { code: 1, message: "Incorrect function." } })

I get that output for any filepath that exists inside of E:\, including E:\ itself. However if I try a filepath that doesn't exist, whether or not it's under E:\, I get this instead:

E:\hello_world>cargo run
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\hello_world'
warning: could not canonicalize path: 'E:\'
   Compiling scratch v0.1.0 (file:///E:/hello_world)
     Running `target\debug\scratch.exe`
Err(Error { repr: Os { code: 2, message: "The system cannot find the file specif
ied." } })

[oconnor663]

This VM is on Virtualbox 5.1.2 on an Arch Linux host:

[alexcrichton]

Aha! Ok I think this is a rustc bug and not a Cargo bug in that case. Basically the compiler's use of fs::canonicalize and ignoring errors is causing it to ignore the information Cargo is giving it.

It looks like for whatever reason the shared folder doesn't implement this filesystem API :(

[oconnor663]

Possibly related: http://python-bugs-list.python.narkive.com/jMhnJ2PS/issue10179-os-stat-fails-on-mapped-network-drive

[alexcrichton]

Perhaps, yeah! I think the fix will be to have the compiler work better with calls to fs::canonicalize or just avoid calling it at all in situations where the filename is already absolute.

[brson]

@alexcrichton Thanks for letting me know. Is rustup's behavior causing badness here or is it just annoying? rustup issue rust-lang/rustup.rs#682

[oconnor663]

@brson I think these examples where we ran rustc directly make it look like rustup isn't causing the problem here, though it's possible something else might be broken that we didn't notice?

[alexcrichton]

@brson I believe the compiler is the root tool at fault here, but the rustup behavior is a bit odd (printing out errors to the console)

[marek-g]

Hi! I've got the same compilation problem on Windows 7 using ImDisk's RAM drive. When I switch to partiton on HDD drive, everything works fine. fs::canonicalize returns Error on RAM drive and Ok on HDD drive.

[carols10cents]

I tried looking through rust-lang/rust's issues and couldn't find anything that sounded exactly like the problems with fs::canonicalize described here, and I don't have a windows virtualbox setup handy to be able to see if this is still an issue.

So I'm going to close this given that if it is still an issue, it should be in rust-lang/rust instead, so if anyone is able to reproduce this, please reopen over there. Thanks!