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