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.
Related
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'm currently taking up a course in COBOL and recently I have only been using an online compiler. When I decided to install the OpenCOBOL IDE. I keep getting the error "cobc: Invalid argument" whenever i try to compile. I tried multiple re-installs still to no avail. I also tried installing just the compiler itself and compiling my files using cmd, but still it gives that error. Any help? I really need to get it working.
OS: Windows 8.1 64-bit
You need an "-x" option to tell the compiler build an executable with the same name as the program source (but without the .cbl or a "-o progname" option to tell the compile to produce an executable named progname.
When I try to create an executable from my Ruby script with ocra's --icon option, the executable seems to compile correctly, but fails to run at execution.
The console gives me a
FATAL ERROR: Invalid opcode '2343724299'.
I tried using different .ico files and the result is the same, EXCEPT the opcode is different.
Using the same script without the icon image yields an executable that executes perfectly fine.
Any ideas as to why?
Environment:
Ruby 1.9.3p448
Ocra 1.3.1
Windows 7 Professional, 64-bit
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!