Prioritizing Windows issues

[brson]

@merg1455 Making Rust on Windows installable in a single step is a priority, and the subject of https://github.com/rust-lang/rust/issues/11782 and https://github.com/rust-lang/rust/issues/16456.

[RobG]

At the very least, some improved installation instructions would be appreciated - there isn’t really a simple guide to getting MinGW working on 64-bit Windows, I’ve just followed 4 “guides” I found on the Web, none of which worked for Rust.

Once again, I’ve given up on Rust until it is a bit more ready, or at least there are some “follow these steps and it just works” instructions.

[rpjohnst]

In the meantime, MinGW-w64 has a few different installers available, which should all work. I’ve used these before:

• msys2: http://msys2.github.io/
• mingw-builds: http://mingw-w64.sourceforge.net/download.php#mingw-builds

Msys2 gives you MinGW and MSYS in one installer, with a package manager. After installing Rust’s nightly and msys2, running install.sh from Cargo’s nightly in msys2’s shell works fine for me.

You mentioned Windows vs MinGW paths; MSYS lets you hand Windows paths to cd and it turns them into its own form like /c/Users/Russell/Downloads/cargo-nightly-i686-w64-mingw32. You can also use that form directly, or put cargo’s files inside your MinGW install (In my case, C:\msys64\home\Russell\ is the default starting directory for msys2’s shell).

[RobG]

I tried that, but there still seems to be some dependency I’m missing, On Linux (Fedora), I can get Cargo itself to run, but fails to build even a simple “Hello” project (i.e. “cargo new Hello” works, but “cargo build” fails). On Windows, I’m nowhere near even that - installing MSYS2 just didn’t produce an environment capable of running the install script (and I did discover how to represent Windows paths).

Even on Fedora, Cargo was failing due to some missing dependency, and I’m simply not experienced enough on Linux/MinGW to diagnose these issues. This is a recurring experience on these platforms - there’s evidently a learning curve involved that I just cannot seem to get over - every open source package I’ve ever tried to compile, for example, requires some dependency that I just cannot resolve.

Sadly (and, I’m glad to report, unlike this forum) mostly I just seem to get abused as a n00b when I ask questions too.

I’d love to experiment with Rust, but just don’t have enough spare time to resolve these issues - I’ll just have to wait until there’s a Windows build that actually works out-of-the-box. The documentation is too Cargo-centered for anything to be useful without it.

Overall though I find the direction of the language itself to have hit a lot of sweet spots for me - I can imagine being productive with the set of facilities available (although I’ve not had, for obvious reasons, any opportunity to prove that).

[rpjohnst]

Hmm, that’s odd. A few things that might have kept it from working: What does msys2 spit out when you try to run install.sh? Did you install the Rust nightly corresponding to the Cargo nightly you used before running it? Did you run pacman -Syu before using msys2?

This might be more work than it’s worth, but thestinger has an Arch Linux repository that’s regularly updated with both Rust and Cargo nightlies. It might not be too bad to install Antergos or maybe plain Arch in a VM and add http://pkgbuild.com/~thestinger/repo/$arch as a repository- then you could just install rust-git and cargo-git.

Either way, a combined Windows installer should solve the problem.

[iliekturtles]

Do you have the error message from cargo build -v on Fedora? I find that after rustup.sh I need to run ldconfig. If ldconfig -p | grep rust doesn’t return any results try sudo ldconfig /usr/local/lib (Or edit /etc/ld.so.conf and then run sudo ldconfig).

[u9520107]

@RobG I can relate to how you feel I guess. Trying to make a simple program to do http request across platform is still not easy. When rust claims to be self contained, and boasting it’s emphasis on supporting windows. Currently it is just too difficult to do anything on windows, when a lot of libs depend on c libs that don’t exist in windows. rust-lang/time depend on gcc headers that you have to install via mingw or msys2 For http request, current working crate is probably hyper, which depend on openssl. The package actually asks you to install openssl on your own, then manually open + rename lib files into the rust installation folder. Call me lazy, but I think if rust intends to have people using cargo as a package management tool, it should be able to handle these kind of issues. I understand that it’s not entirely rust/cargo’s faults, but currently most devs do not seem to care for windows enough to make rust a pleasant language for development in windows.

[andy]

Simply untrue, maybe the languages/compiler you use but I have never seen this using any Microsoft toolchain.

There is no reason, certainly no reason in a windows, why the environment of the compiler would (or even could) affect the generated binaries security demands unless the compiler takes explicit actions to generate different code. Yes, I run in CMD, Bash and even Powershell, as admin most of the time, I have done so for years, and have never seen this.

I am betting you have been running into “installer protection” which only applies to 32 bit processes, something I never build any more, but in that enviroment even the name of the executable can trigger the behavior you describe when you run the binary.

See https://technet.microsoft.com/en-us/library/cc709628(v=ws.10).aspx

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer: • Filename includes keywords like “install,” “setup,” “update,” etc.

• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.

• Keywords in the side-by-side manifest embedded in the executable.

• Keywords in specific StringTable entries linked in the executable.

• Key attributes in the RC data linked in the executable.

• Targeted sequences of bytes within the executable.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.