Prioritizing Windows issues

[brson]

The crumminess of the Rust Windows experience is one of our most pressing problems. I’m trying to understand what needs to be done to fix the situation.

Here are the major problems I’m aware of:

• requires mingw install (https://github.com/rust-lang/rust/issues/11782)
• rustup.sh doesn’t install cargo on windows
• .exe installer doesn’t install cargo
• debugging doesn’t work at all
• No Win64 (https://github.com/rust-lang/rust/issues/1237)
• TCB private slot may be misappropriated (https://github.com/rust-lang/rust/issues/13259)

And here are all the issues on the bug tracker: Issues: https://github.com/rust-lang/rust/issues?page=1&q=is%3Aopen+is%3Aissue+label%3AA-windows

If I were to describe today a project to fix the windows experience better it would be “make the installation easy, make debugging work; oh and fix whatever bugs you can”. To those that have worked with Rust on Windows, what else is critical to fix for the sake of the overall experience?

[shadowmint]

Another issue which I can’t see tracked anywhere:

It appears that on permission managed windows machines (eg. win7) rust generated binaries require administrator privileges to run, even for trivial case applications like println!(“Hello World”); these permissions must be accepted (“Run this as administrator”) every time the application is launched.

I have no idea how this is typically managed in win programming, but having to accept “run this as administrator” every time you run cargo test or launch a binary is really tedious.

[retep998]

How about making cargo builds of any rust library that depend on C libraries not be a complete and total nightmare? Also I’d really love to lose the dependency on that libgcc dll.

[retep998]

I’m using Windows 8.1 and I have never needed to give a rust program administrator privileges.

[brson]

@retep998 Can you provide more information about why ‘making cargo builds of any rust library that depend on C libraries’ is a ‘complete and total nightmare’? Is there a bug filed about it?

[shadowmint]

@brson there’s an extensive reddit thread about it, but in summary: the build step in cargo must know to look at the DEPS_DIR and OUT_DIR to place dlls in the right location. Almost no libraries do this. Most don’t even have a build step and assume the C shared library is just magically already there.

Issues:

1. There is a cargo bug that makes OUT_DIR incorrect.*

2. That the build step has to not only build a library but also copy the result to a specific set of folders is not documented.

3. Rust c bindings almost universally assume that the system has a shared library already available; typically not true on windows where dlls are shipped in the folder of a binary.

4. cargo has no support for detecting missing build tools such as cmake and silently consumes errors if a depency fails to build.

Practically speaking pure rust stuff works great, but c bindings dont work at all (they can work, but virtually none of them do). For something like gfx-rs which has multiple dependencies it really is a nightmare. You have to fork each one and fix their C binding to be static, or add a build step for windows that builds/downloads the appropriate dll.

• (I believe the issue is perhaps tracked by https://github.com/rust-lang/cargo/issues/326)

[retep998]

Its not really so much a problem with cargo and rust as it is a problem with building C/C++ on Windows following the *nix model. So long as I have to continue using mingw I am going to remain unhappy because it hates me every step of the way. As soon as we switch to lld so I can link against proper msvc built libraries I will be so much happier. I mean seriously, trying to build and run an example from glfw-rs, apparently mingw uses such old windows libraries (or possibly some really weird bug) it somehow manages to display the window using the classic theme on Windows 8.1. I didn’t even think that was possible. EDIT: According to eddyb the classic theme is because of rust’s segmented stack stuff interfering with winapi. Oh boy, another reason for why Rust sucks on Windows.

[huon]

there’s an extensive reddit thread about it

Thread in question (it’s really helpful to link to things that can be linked, so that people who aren’t keeping track of everything can still follow, and for future readers when the context has been lost. ).

[pnkfelix]

Can you provide more information about why ‘making cargo builds of any rust library that depend on C libraries’ is a ‘complete and total nightmare’? Is there a bug filed about it?

I recently had some pain in this area (not on Windows; just as a Unix/OS X hacker), due to the difficulty in specifying alternative directories for cargo to feed into rustc via -L directives. It was while trying to solve these problems that I found out (indirectly) about the hack to copy your libraries into OUT_DIR.

Relevant comments I made about this (on issues in the cargo repo):

• could link_config! solve this problem? apparently not.

• my suggestion: let information feed back from the build script to cargo itself.

[brson]

Fixing the test suite so that the bots are running all the crate tests on windows would help with overall quality.

[michaelwoerister]

Debugging doesn’t work on Windows? I was under the impression it worked (with some caveats, e.g. https://github.com/rust-lang/rust/issues/13256). But I admit that I hardly ever have used Rust on Windows…

[retep998]

Regarding debug info, that’s actually the thing stopping make check from passing on Windows.

failures:
    [debuginfo-gdb] debuginfo/function-arg-initialization.rs
    [debuginfo-gdb] debuginfo/function-prologue-stepping-no-split-stack.rs
    [debuginfo-gdb] debuginfo/issue12886.rs
    [debuginfo-gdb] debuginfo/lexical-scope-in-if.rs

[mrec]

There are also quite a few Windows-specific bugs that aren’t tagged as such. Just looking at title, f’rinstance, returns 26:

rust-lang/rust

I tried this because I didn’t see #13810 in the list.

[brson]

@shadowmint Thanks for the explanation.

I’ve added https://github.com/rust-lang/rust/issues/16455 about the permissions issue.

@mrec Thanks for pointing out the untagged bugs. I’ve tagged them.

[brson]

Here’s a metabug containing what I see as the current Windows priorities: https://github.com/rust-lang/rust/issues/16459

[RobG]

Sadly, at the moment Rust is, from my point-of-view, just not ready for Windows development yet. I got Rust itself running quite easily, but the guidelines for installing on Cargo on Windows assume I’m familiar with mingw and MSYS, how to install them and what packages I will need. Most Windows programmers will not be.

I*'m really keen to experiment with Rust, on a Linux VM it all just works fine, but at the moment it seems (like most OSS projects) just not to be a high enough priority to make it seem natural to a Windows developer.

Are there plans to port Cargo to Rust - with Rust itself self-hosting now it seems sad the package manager requires me bringing in so many dependencies, and I’ve never had good experiences with MinGW for any development on Windows. While the dependency on mingw exists, I suspect most Windows programmers will simply not choose to waste there time trying to work around the issues.

I may wait until it reaches v1.0, and see if the situation has improved then. In the meantime I guess I’m stuck with C++ for native development. Shame as it looks like it could be promising.

More detailed installation instructions for Windows may help (as opposed to “You need MSYS and MinGW installed,” along with this list of dependencies - without even links to those dependencies).

[rpjohnst]

Cargo is already written in Rust. The only reason Rust on Windows depends on MinGW is for the linker- but that’s already distributed with the compiler. The simplest solution here is just to get Cargo and Rust installed to the same location, and it looks like the goal for 1.0 is to do just that - distribute Cargo and Rust in the same installer, no messing with MinGW required.

[RobG]

That’s good to know. I just think most Windows programmers will be alienated by the install as it sounds - you need some degree of familiarity with the Unix build system just to get going (in my case, having installed Rust using the Windows installer, I was unsure how to get the Cargo install script to run from a Windows path, as opposed to a MinGW path).

I’ll keep an eye on the project so I spot when a single installer turns up. That would make me more interested.

[tomaka]

Rust and Cargo will eventually be distributed with the same installer, but on the other side many Rust librairies are using a custom build command which requires the user to have MinGW.

[merg1455]

That’s the thing. Windows devs should be able to just download rust and run it, without any further steps. It should be as easily done with node.js. This really needs to become a priority for the language.