cargo test incompatible with latest rustup

[alexcrichton]

The 0.7 release of rustup changed how PATH is managed, and now cargo test where cargo is actually a rustup proxy will no longer work for this project itself.

I believe this has to do with something related to binaries eventually being compiled against the standard library dynamically and then the standard library dll can't be found at runtime. This'll need to be fixed with PATH munging somewhere although I'm not quite sure where.

[alexcrichton]

cc @brson

Also I believe this was caused by rust-lang/rustup#812

[Diggsey]

I think this may be the same as rust-lang/rustup/issues/765

The solution may be different on linux, but on windows I would expect the build tool (in this case cargo) to copy any required dynamic libraries into the output folder.

This would solve the problem for not just cargo test, but for all projects dynamically linking to other crates. It would also make it clearer to the end-user that they need to distribute these additional DLLs with their program.

[retep998]

@Diggsey But the output folder for cargo install is shared among all your toolchains, and your toolchains each have their own versions of the dlls.

[Diggsey]

@retep998 You also can't cargo install the same executable from different toolchains, do you have a reason to use anything other than a single "host" toolchain while cargo installing?

[retep998]

@Diggsey Imagine someone who cargo installs several different binaries, but over a period of time, and uses nightly. Each binary would depend on different nightly dlls.

[Diggsey]

Regardless of what rustup does, I don't think we can ever really support that without significant work to store DLLs in a namespaced subdirectory - or until rust gets a stable ABI

[masaeedu]

@alexcrichton Wouldn't this be a rustup bug? If I cargo install a program from source, the resulting binary can't run without the appropriate toolchain DLLs on my PATH (see https://github.com/Manishearth/rust-clippy/issues/1422). What tool's responsibility is this?

PS: Apologies in advance if that doesn't make any sense; I'm on quite the adventure here trying to set up a Hello World project in VS Code

[Diggsey]

@masaeedu As @alexcrichton said, for cargo test specifically, there are a number of places this could be fixed, because cargo test is not expected to work without a copy of the toolchain used to compile the test binaries.

However, for cargo install, or just generally when dynamically linking, there is nothing that rustup can do, since it plays no role in that process.

[pravic]

@retep998

Imagine someone who cargo installs several different binaries, but over a period of time, and uses nightly.

I think, it would be easier to update tools with the nightly together (or just use some time-frozen nightly version with bunch of tools) than to do nothing. Because currently all compiler-dependent tools are just broken.

[carols10cents]

I believe this was fixed in #3996. Closing!