what happen to gfortran compiler

[zmth]

i have used
gfortran.exe uses.f95 and use gfortran.exe myfile.f95 such as
this aLL files that worked perfectly and compiled no problem
prior now get message. eg Get error

:\Simply Fortran 2>gfortran.exe uses.f95
his version of c:\Simply Fortran 2\gfortran.exe is not compatible with the version of Windo
s you're running. Check your computer's system information to see whether you need a x86 (3
-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

I am doing exaclty the same thing and never got this message before ! Why NOW ?

 

[xwb]

Have you upgraded to W10?

Which version of gfortran are you using (gfortran --version)

 

[mikrom]

Here is the info

http://answers.microsoft.com/en-us/...ble-with/0c6a4c8e-1416-47a5-b6b4-6d10a82942da

 

[xwb]

Check your windows updates on the day it stopped working.

 

[zmth]

No, have not upgraded or changed anything, still windows 7. I am pretty sure it is a 'bogus' incorrect message and I am pretty sure I do have 64bit capability-anyway nothing has changed unless I accidently pushed some wrong keystrokes which I often do and in fact on that occasion certainly did as the source file got really 'muffed' also. Unfortunately I did not think to carefully look at the DOS screen. I did not compile within code blocks as usually don't as it does not work for module anyway. I do the compile in DOS window direct.
I forgot what version it was. i remember there was a way to tell once and i did it but have forgotten how to do that. But get the following when do gcc -v

c:\Simply Fortran 2>gcc -v
Built by Equation Solution <

http://www.Equation.com>.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/tdm-gcc-32/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.8.2-mingw/configure --host=x86_64-w64-mingw32 --build=x86_64-unkno
wn-linux-gnu --target=x86_64-w64-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/nat
ive/x86_64/gcc/4.8.2 --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/
4.8.2 --with-gcc --with-gnu-ld --with-gnu-as --with-gmp=/home/gfortran/gcc-home/binary/mingw
32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpfr -
-with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpc --with-cloog=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/cloog --with-isl=/home/gfortran/gcc-home/binary/min
gw32/native/x86_64/isl --enable-cloog-backend=isl --enable-targets=i686-w64-mingw32,x86_64-w
64-mingw32 --enable-lto --enable-languages=c,c++,fortran --enable-threads=win32 --enable-sta
tic --enable-shared=lto-plugin --enable-plugins --enable-ld=yes --enable-libquadmath --enabl
e-libquadmath-support --enable-libgomp --disable-nls --disable-tls --disable-win32-registry
Thread model: win32
gcc version 4.8.2 (GCC)

I don't think the above is of much relevance though. It is gfortran.exe of 2,023kb. My date on it shows 1/26/2015 but am
pretty sure that date is likely only particular to when I installed.

 

[zmth]

Oh OK NEVEr mind now found the problem . Wasn't expecting something that blatant. Another thing that seems strange is why do 2 different versions of gfortran NOT even close in size in different directories with very different subdirectory structure and other files give exactly the same as above when
Do gcc -v. Though it could somehow be using the same files etc. ?

 

[Beilstwh]

Personally I do a full load of cgywin on my windows 7 64 bit and put it's bin directory in my path variable. Now I have all the UNIX utilities on my windows machine with all their functionally and that includes gfortran. Before I did this I uninstalled all versions of gfortran that were already on my machine.

Bill
Lead Application Developer
New York State, USA

 

[salgerman]

Say, Bill, I did not think cygwin and mingw were the same thing, though; unless they have changed cygwin since last time I used it. As far as I knew, when you compile with cygwin, your program is not a self-contained program and it has to have access to some cygwin.dll at run-time; on the flip side, I think a program compiled with mingw is truly self-contained and can be given to somebody else without mingw.

Maybe just a detail, but worth being aware of it.

 

[xwb]

Probably worth doing a test build after you download a mingw compiler. Sometimes it doesn't get build correctly and has a dependency on cygwin - this has happened quite a few times. If you use cygwin, you may run into problems if you use utilities which are not part of cygwin but which require a different versions of cygwin.dll

 

[Beilstwh]

Thats true, however all you have to do is store the cygwin1.dll file in the same directory as the exe and everything will work fine. I will check into mingw. Thanks for the info

Bill
Lead Application Developer
New York State, USA