Recently, Intel released Ifort compiler for free, for everyone to use. As I have been using gfrotran for quite some time, I decided to install it. I installed the two packages that intel says they are needed (using Windows 10). In the console, as ifort was not recognised (I tried to set up the path to the executable ifort.exe to no avail), i decided to use intel one api tool console.
In that console, ifort is recognised, and you can acces help options and the likes. However, when I try to run a simple test program, it runs with fatal error LNK1104, where imageHlp.lib is missing.
I also tried to run it form the VS17 interface, but it was futile.
I don't know what I am doing wrong, and Intel support forums are in permanent "we are experiencing network issues".
I just want to compile a text file to an executable, no libraries involved, nothing fancy.
I am not seeing any issue with the Intel forums. Make sure you have configured VS2019 for the "C++ Desktop Workload" - see https://software.intel.com/content/www/us/en/develop/articles/installing-microsoft-visual-studio-2019-for-use-with-intel-compilers.html Or for VS2017, https://software.intel.com/en-us/articles/intel-c-fortran-compilers-for-windows-integration-into-microsoft-visual-studio-2017
After you have installed the oneAPI HPC Toolkit, there is a shortcut created Intel oneAPI > Intel oneAPI command prompt. Use this to establish the environment. But you will probably find that the default directory with that shortcut is C:\Program Files (x86)\Intel\oneAPI, which is unusable for compilation, so "cd" to a writable directory. (I like to copy that shortcut to my desktop and modify the "Start in" location.)
Related
Running Makefile in CLion. The Makefile is of stockfish(chess) and is here https://github.com/official-stockfish/Stockfish/blob/master/src/Makefile
I am trying this on a windows 10 system.
Why is make unable to find the file? Is it a the separator issue of \ vs / on linux vs windows?
Full error
Error running 'Makefile': Cannot run program "\usr\bin\make" (in directory "C:\Users\anmol\Desktop\Coding\stockfish\src"): CreateProcess error=2, The system cannot find the file specified
My version of CLion has makefile support inbuilt and I have toolchain compilers installed via cygwin.
The full explanation of your problem is given in this comment in the JetBrains bug tracking system.
The Cannot run program "\usr\bin\make" error originates from the Makefile language plug-in which comes bundled with CLion and can be added to other JetBrains' IDEs, too. Despite being bundled, the plug-in was originally a 3rd-party one and is not a part of Makefile support in CLion: to some extent, it complements the built-in support for Makefile projects (e. g.: by enabling syntax highlighting), but has some functionality orthogonal to that.
That "orthogonal" functionality is, particularly, the way the plug-in runs Make (when you click the gutter icon from the Makefile editor). This has nothing to do with Toolchains in CLion and needs to be configured separately.
Cygwin
MinGW
You'll need to type the full Windows path into the text field (e. g.: C:\cygwin64\bin\make.exe) and either check the Use Cygwin box (for Cygwin) or leave it unchecked (for MinGW).
WSL
As of version 2022.1, the plug-in also supports running Make inside WSL guest VMs. See this section in the official documentation for more details.
Following the above guidelines will enable you to invoke Make targets from the Makefile editor (using any JetBrains IDE with the plug-in installed, not just CLion).
Workaround:
In a CLion Makefile project, two "Configuration" types are available:
"Makefile Target" and "Makefile Application". If you edit a "Makefile Application" configuration, you will see a field called "Executable: "
The "Executable: " can be any Linux command including make itself. For "Makefile Application" (not "Makefile Target") the command is properly initiated using wsl.exe so that the command is run in WSL and not Windows.
(The problem with "Makefile Target" is obviously a CLion/plugin bug whereby "\usr\bin\make" is not run using wsl.exe, so it's run in Windows, so Windows is saying that it can't find it, which is expected because it's not supposed to be run in Windows to begin with! :-) )
So I get a bit confused on the many possibilities here. I have a CMakeLists.txt, which is hopefully all ready to be used. I am using WSL in the Windows Terminal and switching between microsofts cmd.exe and ubuntu wsl terminal on which I want to be able to run the compile command. So on which side do I need to run cmake and what build-files should I generate or what compiler should I use?
Main goal is having a simple compile cmd in vim on wsl, that compiles the exe for windows.
I tried to setup the build files with cmake from the wsl-side with the mingw cross-compiler, but during project setup it failed to find glfw3 configurations, which felt rather weird since it should use windows glfw files anways, right(?)
Next closest try was to create the build files with cmake from the cmd-site with the cl.exe compiler and ninja. That succeeded, but when now running ninja on the wsl side I get a lot of warnings concerning the unknown cmd option \O0 and fatal errors concerning not being able to include simple files like float.h, stdio.h, Windows.h etc. .
All my current search led me to this point, but I am not able to come up with a solution. So I would love to get some help. I want to stick mainly on the linux side, when programming but in the end have an executable for windows.
I installed both VS2013 and VS2015 Professional (full install), and both have a "armasm.exe" under the bin folder. I set the bin folder into "path" environment variable. When I tried "armasm /?" under cmd, it prompts out a dialog box with a red cross sign, saying that:
The application was unable to start correctly (0x000007b). Click OK to close the application.
I wonder if this program is for ARM CPU's assembly language. Does this program only run on ARM machine that installed VS?
How can I get it to run?
I assume you're talking about the armasm.exe file in the \VC\bin\x86_arm folder? If so, then no, that is an x86 binary, not an ARM binary. It will run on your machine.
It is actually an ARM cross-assembler for x86. That means it allows you to assemble ARM binaries on an x86 host. Think of it like the x64 cross-compiler for x86 (in the x86_amd64) folder. That can compile 64-bit binaries on a 32-bit x86 host.
The reason you can't get it to start is because the environment has not been set up correctly, and required dependencies cannot be located. When I try to start it, I get a more descriptive message than you do:
System Error:
The program can't start because msvcdis140.dll is missing from your computer. Try reinstalling the program to fix this problem.
You are meant to use the vcvarsx86_arm.bat batch file (in the same folder) to get your environment set up correctly, before trying to run any of the tools. Step-by-step:
Open a new Command Prompt.
Drag in vcvarsx86_arm.bat, and press Enter to run it. This sets up your environment to run the x86/ARM tools.
Drag in armasm.exe (or simply type armasm.exe into the prompt, unqualified). It will now run because the environment has been correctly set up (including the path, so that it can be found without requiring the full path to be entered).
There is also a \VC\bin\amd64_arm folder. This contains tools for ARM executables that run on x64 hosts. You use those in exactly the same way, except you launch the vcvarsamd64_arm.bat file in that folder first.
It is worth noting that I also see a \VC\bin\arm folder, but (at least in my install of VS 2015) that contains only one EXE: pgosweep.exe. Microsoft does not appear to provide an ARM assembler that runs on ARM platforms. Which makes sense—I don't think ARM is a supported host for development. Visual Studio certainly hasn't been ported to ARM. Just use the ARM tools on x86 or x64.
I'm trying to debug a crash in my program running on cygwin. The program has been compiled and linked using visual studio 12 tools. A trial license for the full vs12 version has been installed so presumably we have access to the vs12 debugger. I've never used this before, I'm more familiar with command line tools in linux like gdb or lldb on osx. It doesn't seem that gdb is installed on our windows machines and I don't have admin access. I'd like to simply run a backtrace on the program at the point at which it fails. Can anyone give a quick start for using the debugging tools on cygwin/windows? I've tried the following
$devenv /debugexe /winsame/swsides/myexec 'program-options'
A microsoft visual studio window opens up, but again I'm not clear on where to start. It would be great if there was a simple command line interface.
I'm having some trouble installing and configuring qt on my vista laptop.
I'm trying to setup a development environment on my laptop where I compile from the command line, because that's how the environment is setup on my university's linux machines, so I don't want to tie myself to some IDE .. (plus, real programmers use the command line!)
I haven't used the command line before for C++ development, it was all MSVC, so now I'm having a bit of trouble.
I'm still using MSVC, but from the command line. I practically have no idea what's going on, I just know that I have to run:
qmake
nmake
to compile my code!
I downloaded the opensource version of qt, and did the configuration, and tried a simple qt application (from a tutorial) and it worked, it compiled and executed pretty much as expected.
Now, when I decided to run another project that uses opengl, I got the following error:
fatal error C1083: Cannot open include file: 'qgl.h': No such file
or directory
I'm not sure where does the compiler look for header files, and I didn't copy any header files anywhere, I assume that configure.exe worked its magic somehow and added the include directory to one or more enviroment variables or to some registery location or whatever other peculier places that the MSVC compiler searches for to find include directories.
However, what I did was search my C:\qt\include\ folder to make sure that qgl.h exists, and sure enough there it was. so why can't nmake find it?
I think the actual solution to this is in your pro file:
QT += opengl
If you want to stay with the command line anyway (plus use it on a linux box later / parallel) I'd suggest at least trying out the MinGW version of Qt. I'm using it regularly, and besides of the non-existance of a GUI it works pretty well. Using MinGW also has the advantage that you can simply download and install the MinGW edition of Qt and don't need to reconfigure or recompile anything.
Also, trying out QtCreator might be interesting. It's still beta and requires the beta Qt 4.5 but it's a nice small IDE that integrates nicely with gcc.
Two potential solutions (they solved issues at my workplace)
Do you have qt include and bin folders in the PATH variable? I think the doc says only one of these is needed, but one of the students had Vista and putting the other in the PATH variable solved a "Cannot open include file" problem.
If you're using MSVC did you run configure and nmake from the Visual Studio command prompt? We had problems when using the bare windows Command Prompt because the VS one adds a lot of temporary environment variables to the configure process.
Good luck
Install the complete Qt SDK for Windows which includes Qt 4.6 SDK, Qt Creator 1.3, and MinGW.
It will also install "Qt Command Prompt" launcher that you can use to build Qt apps from the command line.
I'm sure you're more familiar with MSVC than MinGW, as I do too (I've been using MSVC 6.0 to MSVC# 2008 for developing .NET apps).
But try MinGW with Qt and I think it's better for long term. I do some C++ development on Linux too so getting familiar with MinGW will be beneficial for you in cross-platform C++/Qt development.
For more info, see Installation of Qt 4.6 SDK for Windows.
Qmake generates Makefile from *.pro file located in current directory. It has qt path compiled in. Type "qmake -v" to see it. You can't move qt's dir after compiling it. If You haven't moved it, first maybe try to install Qt following instruction from INSTALL file. Good luck.
The opensource version of Qt does not provide profiles (mkspecs in qt terms) so qmake can generate nmake (msvc) compatible makefiles.
You have to use mingw/gcc.