`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.