Closed ljedrz closed 6 years ago
so, what is USERNAME
? :-)
It appears that it doesn't need to be a user folder - a different location, C:\bęc\my_project
doesn't work either, while C:\bec\my_project
works just fine. I think it's GCC-specific, as it's GCC that's reporting the errors; you can see an error log here.
My cargo.toml
looks as follows:
[package]
name = "my_project"
version = "0.1.0"
authors = ["ljedrz"]
[dependencies]
calamine = "0.14.1"
chrono = "0.4.2"
csv = "^1.0"
image = "0.19.0"
log = "0.4.1"
rand = "0.5"
simplelog = "0.5.2"
sxd-document = "0.2.6"
sxd-xpath = "0.4.1"
[dependencies.conrod]
version = "0.60.0"
features = ["winit", "glium"]
It's unfortunately known that gcc can't handle non-ascii names on linker command lines sometimes. This isn't really a Cargo issue per se but is moreso a rustc issue. Is it possible to switch to the MSVC toolchain or project folder?
I'm amazed gcc hasn't fixed this sort of thing by now. It's not a big deal for me, I could just change the name. Since it's not cargo-specific I guess the issue can be closed.
Ok I'm gonna close this in that case, and there's some more information (although not super helpful) in https://github.com/rust-lang/rust/issues/48737
I wanted to compile one of my projects on a different Windows PC than usual but I was surprised that cargo was not able to find the downloaded dependencies in the target folder, even though the paths in the error message were available.
I suspected that a non-ASCII username was the cause, so I moved the project folder outside the C:\Users\USERNAME folder. It seemed to have helped, but
cargo
was still having difficulty - this time finding its .cache. I set theCARGO_HOME
env variable to a folder outside of the default C:\Users\USERNAME and it worked.TL;DR: it seems that
cargo
,rustc
orgcc
has trouble working with non-ASCII paths on Windows (at least Windows 10). I am using a standalone installation of Rust 1.26.2 x64 GNU.