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.
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.)
I am trying to get some code running which uses make. I've downloaded and installed both MinGW (standard 32 bit) and TDM-GCCs flavor of MinGW on my 64-bit Windows 7 machine.
When I run make (i.e. mingw32-make.exe) in Administrator mode, I get the following error message:
Windows cannot access the specified path, or file. You may not have the appropriate permissions to access the item.
The weird/scary part is that, upon running, it immediately deletes the exe file.
I ran a checksum SHA1 as recommended in the comments using the Microsoft (R) File Checksum Integrity Verifier V2.05:
C:\path\to\folder>fciv.exe -sha1 mingw32-make.exe
//
// File Checksum Integrity Verifier version 2.05.
//
c8ae5c780ab7bed652883d6443b5bfe5e23d30c9 mingw32-make.exe
I don't understand what this output means, but maybe it's helpful to someone.
Notes:
This happens regardless of where the file is located on my pc.
This behavior is specific to the make program (others such as gfortran and gcc appear to be working fine)
Renaming the file makes no difference.
I am an administrator on the pc
Same behavior when I run the program from the explorer or command line.
My anti-virus program (Avast) does not detect any problems with the file when I scan it.
I got the MinGW setup file from this SourceForge page.
I got the TDM-GCC web installer from this page.
The file size is 219,662 bytes (from both the main MinGW and TDM-GCC packages)
I have run make from the command line where I have started the command prompt by way of selecting Run as Administrator in the context menu.
I have also tried to run make by selecting Run as Administrator when I have it selected.
I run the command mingw32-make when this behavior occurs. I have also tried renaming it to things like make and foo with the same result.
The first time this happened with both MinGW it deleted the original file and I re-installed it using the mingw-get application. From thereon after I started making copies of the original mingw32-make for testing.
For the make executable, I have all permissions (including Read & execute) except the special permissions field.
After using the process manager I found out it was indeed Avast that was the problem :S A couple of lines revealed avast actually deleted the file before windows got around to executing it, which was the reason for the windows message. I put Avast on 'Silent Mode' a while back; I thought the only purpose of this mode was to suppress notifications about minor updates, but apparently it also gave Avast permission to deal with 'threats' silently as well.
After figuring that out the solution was straightforward. I just went into the settings and created an exception for the mingw32-make.exe file. It now runs without issue.
Thanks very much for your help everyone!
User account has administrator privilege but when user started to work , not all privilege are taken in account , just start your application for compiling with run with administrator mode try this : https://technet.microsoft.com/en-in/library/cc781763(v=ws.10).aspx
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.
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
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!