Prioritizing Windows issues

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

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.

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

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

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

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.

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

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

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 Understanding and Configuring User Account Control in Windows Vista | Microsoft Learn

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.

1 Like

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