I am trying to make a code run on my machine (windows 7 x64), it is a fortran 90 code that needs a third-party provided i386-based dll to work.
When I tried compiling it (with latest gfortran and mingw) to a x64 target, it refused, because of the i386 dll file. Then, I tried to compile it to a i686 target, and the compilation worked without errors.
However, the output a.exe file won't run on my x64 windows (as one could expect), and when trying to run it from Dosbox (just typing "a" or "a.exe" when I reached the correct directory), I just got "this program cannot be run in DOS mode".
So my question is: is it a fail in the compiling process, or does Dosbox reject the program for some reason (the reason being possibly that the "a.exe" program needs to write to a file when executed: it is its purpose, actually!), and if it is so, what is the reason, and is there a way to ultimately see my exe file run? on my machine?
EDIT: Dosbox indeed can run a 32 bit exe file I have from another project, so it is not Dosbox being completely non-functional. However, when trying to open that exe file directly with windows 7, it says it is incompatible with x64, while for the other file (a.exe) it just says it "fails to initialize" with code "0xC000007b"...unfortunately my compiler debugging knowledge is close to zero...
Thank you very much for your help!
Related
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.)
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.
Preface: Using cygwin on a Win7 machine.
I have some old (very old) f77 code (45,000 lines in 25 files) written by someone else that I am trying to use.
Yesterday I compiled, linked and ran it OK (using f77 compiler). I then made some mods (increasing array sizes) and kept getting segmentation faults when executing. Wondering if there was a compatibility problem I then fiddled with the settings in Windows (to no avail).
Now I cannot even run the compiled program - I get a "cannot execute binary file" error. I cannot even compile and run the original version of the code.
There were only some minor warnings during the compiling and none during the linking.
I have:
Checked permissions (all OK:- user::rwx)
Checked via file and get: "PE32 executable (console) Intel 80386, for MS Windows".
Written a test program to check my compiler commands and it ran as expected.
Copied all source code to another directory to see if that was problem (it didn't help).
Tried to run the executable from a windows command prompt and get "not a valid Win32 application" (and yet a previous executable executes OK).
What may have happened between yesterday and today that is stopping this program executing. Is it related to my fiddling with the compatibility settings? Or is it something in the code that lets it compile and link OK but not execute?
Any ideas appreciated.
I have the following code:
PROGRAM TEST
IMPLICIT NONE
PRINT *, "test"
END PROGRAM TEST
It is compiled successfully using this command:
C:/cygwin64/bin/x86_64-w64-mingw32-gfortran.exe test.f08 -o test.exe
When I run the program by double clicking it, it produces the error:
"The application was unable to start correctly (0xc000007b). Click OK to close the application."
The file libgfortran-3.dll is in the same folder as the executable. My environment is Windows 8.1 64-bit. Cygwin (Setup.exe version 2.850 (64 bit)) is installed to C:\cyginw64. All defaults packages were installed, along with all "Base" and "Devel" packages. My system PATH environment variable includes C:\cygwin64\bin. Running the program from the Cygwin64 terminal produces no output.
What is causing this error? I have another, more complicated program that suffers from the same error.
Possibly related: why gfortran under cygwin can't compile correctly?
That error code is an NTSTATUS code, specifically STATUS_INVALID_IMAGE_FORMAT. Almost without fail that means you are trying to load a 32 bit module into a 64 bit process. Or vice versa. Use a dependency analysis tool to work out which module has the wrong bitness. For example Dependency Walker.