I'm new to rust and would like to debug my Rust code using Clion (19.3 currently) and followed this answer to switch the compiler from MSVC to GNU, Now when I run my program (in debug) I get this error from Clion:
com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: Error creating process <Program Path>, (error 50).
Though running without debugging works fine.
If I google the error I get this issue on github which essentially says use a 64bit compiler on a 64bit app. The compiler I added is 64 bit and since I installed the 64 bit version of rust I assume that the programs that it outputs are 64bit... (though I don't know enough about rust to be 100% sure)
Running rustup show returns this:
rustup show
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\User\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-gnu (default)
stable-x86_64-pc-windows-msvc
active toolchain
----------------
stable-x86_64-pc-windows-gnu (default)
rustc 1.42.0 (b8cedc004 2020-03-09)
Which is where I'm getting the idea that the correct toolchain is being used (as it says x86_64 all over the place).
Where as I going wrong? and what is miss configured?
Turns out that I'm super dumb and had the Clion pointing at a 32 bit install rather than the 64 bit install. I ended up following this guide by Jetbrains themselves: https://blog.jetbrains.com/clion/2019/10/debugging-rust-code-in-clion/
On Windows, go to Settings | Build, Execution, Deployment | Toolchain and set either Cygwin or MinGW as your working environment. Then, run rustup toolchain list and check the first line: it should be one of the gnu versions matching the bitness of the debugger. For example, if you’re working on MinGW (32-bit), the default toolchain should be i686-pc-windows-gnu. If you’re on MinGW64, it should be x86_64-pc-windows-gnu. You can set the appropriate toolchain by running rustup default "toolchain_name".
Update October 2021
Jetbrains have release an updated blog post that shows some improvements they have made to the debug process, for example on windows you no longer need to change settings in order to get debugging to work! https://blog.jetbrains.com/rust/2021/10/19/debugging-rust-in-jetbrains-ides-state-of-affairs/
Related
I tried to install Rust on Cygwin but failed to be able link with mingw. Now I am trying to install it with Msys2. I already installed Msys2 and Mingw. I tried to follow this wiki page but I got lost at number 2:
Download and install Rust+Cargo using the installer but be sure to disable the Linker and platform libraries option.
Is it referring to the "rustup-init.exe" on the install page? Should I double click to run this file or run it from Msys2? I tried to run from Msys2 and got the options:
1) Proceed with installation (default)
2) Customize installation
3) Cancel installation
I don't know what to do next.
The Using Rust on Windows page you linked to dates from before rustup replaced the installer as the default option to install Rust. Installers are still available, but you should use rustup if possible, because it makes it easy to update and to use multiple toolchains at once (e.g. stable, beta and nightly). If you must use the installer, just select the x86_64-pc-windows-gnu installer and follow the step from the Using Rust on Windows page. If you're using rustup, read on.
By default, rustup on Windows installs the compiler and tools targeting the MSVC toolchain, rather than the GNU/MinGW-w64 toolchain. At the initial menu, select 2) Customize installation. When asked for a host triple, enter x86_64-pc-windows-gnu. Then make a choice for the other questions, then proceed with the installation.
Note: If rustup is already installed, then rerunning rustup-init won't actually install the requested toolchain. Instead, run rustup toolchain install stable-x86_64-pc-windows-gnu if you already have the MSVC-based toolchain. Then run rustup default stable-x86_64-pc-windows-gnu to set the GNU-based toolchain as the default.
Rustup will install the MinGW linker and platform libraries automatically (as part of the rust-mingw component) and refuses to let you remove them. If you prefer to use the MinGW linker and libraries you installed with MSYS2, you'll need to create a .cargo/config file (either in your profile directory, i.e. C:\Users\you\.cargo\config, or in your project's directory if this configuration is specific to a project). The contents of that file might look like this:
[target.x86_64-pc-windows-gnu]
linker = "C:\\msys2\\mingw64\\bin\\gcc.exe"
ar = "C:\\msys2\\mingw64\\bin\\ar.exe"
Rustup will modify the PATH environment variable unless you told it not to. However, MSYS2 resets PATH by default when you launch, so when you try to invoke cargo or rustc from your MSYS2 shell, it might not find it. You'll need to edit your .profile/.bash_profile script to set the PATH correctly (you need to prepend /c/Users/yourname/.cargo/bin: to PATH).
my problem resolved by following way
Run rustup toolchain install stable-x86_64-pc-windows-gnu
Second open .rustup folder
Open settings.toml file
Change first line with: default_toolchain = "stable-x86_64-pc-windows-gnu"
done!
I wrote a complete guide on how to
install Rust on windows with Visual Studio Code and MSYS2 MinGW
on the page found here:
https://stackoverflow.com/a/68835925/4230643
I wrote a little game using Rust, and I used cargo build --release to compile a release version on Mac.
I tried to share this with my friend who is using Ubuntu, but when he tried to run the binary, he got the following error:
cannot execute binary file: Exec format error
I searched for this but found no answers. Doesn't Rust claim to have "no runtime"? Shouldn't it be able to run anywhere in binary form?
Rust not having a runtime means that it doesn't have a lot of code running as part of the language (for example a garbage collector or bytecode interpreter). It does still need to use operating system primitives (i.e. syscalls), and these are different on MacOS and Linux.
What you want is a cross compiler. If you're using rustup, then installing a cross compiler should be simple:
# Install the toolchain to build Linux x86_64 binaries
rustup target add x86_64-unknown-linux-gnu
Then building is:
cargo build --release --target=x86_64-unknown-linux-gnu
Caveat: I don't have an OS X machine to test this on; please comment or edit to fix this if it works!
Well, it is because Rust has no runtime (unlike e.g. Java's JVM) that you can't just compile code on one OS and expect it to run on a different one; what you are looking for is cross-compilation. I haven't done it in Rust, but from what I can gather you can find relevant information on different cross-compilation Rust strategies on this GitHub repo.
TL:DR;
Can I write GUI programs on Win 10 (64) using Rust without installing the full MinGW toolchain (nor the MS equivalent)?
Supplementary questions:
- If not, should I just go ahead and install MinGW?
- Does anything GNUish in Windows 10 Anniversary Update change any of this?
Longer version
I saw that Rust is the most loved programming language hereabouts so 15 minutes ago...
I read
No additional software installation is necessary for basic use of the GNU build.
Rust's support for the GNU ABI is more mature, and is recommended for typical uses.
So I downloaded Windows (GNU ABI †) (.msi) 64-bit to my PC running Windows 10.
TUI
I read some basic intro and used rustc to compile a Hello World! and ran it OK. I then read about cargo and reorganised buit and ran the same code using that.
GUI
I then searched for Rust GUI and found Kiss_UI
a simple UI tookit for Rust
So I did a cargo new Hello_GUI --bin and added
[dependencies.kiss-ui]
git = "https://github.com/cybergeek94/kiss-ui"
to Cargo.toml
I cut and pasted a simple example from that website into main.rs
I then ran cargo run --verbose. It did
Updating git repository `https://github.com/cybergeek94/kiss-ui`
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading iup-sys v0.0.3
Downloading libc v0.2.14
Downloading libc v0.1.12
Compiling libc v0.1.12
...
warning: crate `Hello_GUI` should have a snake case name such as `hello_gui`, #[warn(non_snake_case)] on by default
error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" ...
note: ld: cannot find -liup
error: aborting due to previous error
So I learned two things
I need to use snake case.
GUI programming is not "basic use".
I have no complaints about either of these points but could use a clue or two about the second:
Assuming I want to write a GUI equivalent of Hello World in a simple way, what are my main options now?
According to its documentation, kiss-UI depends on the IUP library.
The error from gcc (can't find -liup) suggests that you don't have IUP installed. You may be able to install it and have things work; it depends on whether the IUP bindings used by kiss-UI can cope with windows.
Some other GUI libraries can be found at awesome-rust. There are bindings to libraries like Qt and Gtk. If you know the windows API, you could also check out the winapi crate.
If you want to avoid messing with linking and stuff, you could try using a pure rust library like conrod, which should 'just work' on windows.
To answer your more broad questions:
See the footnote on the downloads page. The MSVC version of rust depends on MSVC being installed. The GNU/MinGW build is standalone.
I have a strange error with qmake: To compile octomap, first I need to compile octovis code, accordingly with documentation I need to use:
cd octovis/src/extern/QGLViewer
qmake
mingw32-make
But when I use qmake, they just do nothing, seeing the task monitor the amount of memory used is constant and the amount of processor used is 0.
I tried to uninstall/reinstall QT and MinGW, and didn't work, I have change the version of QT (4.8.5, 4.8.6, 5.5) and MinGW and didn't work, I'm using windows 7 over 64 bits. I appreciate any solution.
I was able to generate the qmake files with no problem. make failed, but my environment is QT 5.5.1, which I doubt is compatible. I can tell you how my environment is set up, and that should get you going.
Go ahead and download QT Creator for whatever version of QT you require. This includes the appropriate mingw version, so they don't need to be downloaded separately. http://download.qt.io/archive/qt/
Find out what version of QT is recommended. It looks like 4.X, but I'm not 100 percent certain.
Add X:/QTCREATOR/QTVERSION/mingw/bin to your system path, with QTCREATOR being the root directory for QT Creator and QTVERSION being the version. These are included with the QT Creator install.
Also add X:/QTCREATOR/Tools/mingw/bin to your system path.
I'm assuming you have CMake already. That's obviously required.
This should have your build environment set up properly. You're sure to encounter other problems along the way.
The best option appears to just run it under Linux. There are pre-compiled binaries.
I am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b