Modify the PATH in multirustproxy for Windows support

[SpaceManiac]

On Windows, shared libraries (DLLs) are searched for in the PATH, so it should be pointed to the $sysroot/bin directory where the DLLs are in the Windows Rust packages.

rustup is also changed to point to a version which includes rust-lang/rustup#29. This is sufficient, in my testing, to make multirust at least minimally functional under MSYS.

This has the side effect of causing cargo calls to rustc and rustdoc to just call the toolchain binaries directly rather than go through the proxies again. This shouldn't cause any problems, but I currently don't have a Linux machine to test on. If this behavior isn't desired, a check to only update PATH on windows could be added.

[brson]

Thanks! I'll give some thought to the proxy issue - I can definitely think of ways it will change behavior, since currently multirustproxy sneaks in the -C rpath flag to all invocations (though I plan to stop that).

[SpaceManiac]

I actually did run into a problem where a compiled executable linking C libraries was finding the libstdc++ and libgcc dlls from the Rust install rather than the one it was compiled against. I was able to resolve this by appending $sysroot/bin at the end of the PATH rather than at the beginning; it seems like that might also restore the current proxy behavior, while allowing Windows runs to find the Rust DLLs.

[brson]

@SpaceManiac ok, thanks for the note about that. I'm going to be working on this today - really want to get this working.

[brson]

@SpaceManiac After consideration, I'm not sure that adding to the $PATH accomplishes anything. Since the bins and libs are in the same directory on windows, and windows searches the application directory for dlls, it already finds the dylibs needed by rustc itself (I tested this locally). Does that make sense? Are there other cases that I'm not thinking of?

The non-rustc dylib case I'm currently considering out-of-scope for multirust (see removal of -C rpath).

[brson]

I went ahead and pushed a patch to update rustup as a start.

[SpaceManiac]

As we discussed on IRC, 1.3.0 stable dynamically links libstd in buildscripts, so the PATH change is still needed on Windows. This behavior is changed in 1.4.0-beta.1, so this patch isn't needed there and onwards, at least in the situations I am aware of.

[brson]

OK. I'm going to do the PATH change, at least temporarily, but by appending instead of prepending. I'll just do it locally since I've got some other patches lined up for windows.

[brson]

My branch: #100