Topic: File "is not a valid Win32 application" SF 2.30 build 2281

I am having a couple of baffling issues. The first is the above system message after editing my source and compiling. The compile is normal and completes without issue. The new executable has a new time stamp indicating it was just created. When I try to execute the new program I get the system message as in the title. How I got to this point was that I modified my running code by copying a subroutine and pasting it within  the same program and renamed it as something else; essentially having two identical subroutines (with different names) but the new/copied subroutine is not called by the new executable. Old program worked fine, the new one gets rejected by the OS.

Here are the test from the create and makefile:

==============================================================================
Generating Makefile... Okay
==============================================================================
Compiling .\riod.f
f951.exe: Warning: Flag '-fmax-stack-var-size=20000000' overwrites '-frecursive' implied by '-fopenmp'
Generating riod.exe

* Complete *

#
# Automagically generated by Approximatrix Simply Fortran 2.30
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f

IDIR=

LDIR=


OPTFLAGS= -O3 -fgraphite-identity -floop-interchange -floop-strip-mine -floop-block -floop-parallelize-all -mtune=broadwell

SPECIALFLAGS=-m32 $(IDIR)

RCFLAGS=-O coff -F pe-i386

PRJ_FFLAGS=-fopenmp -fmax-stack-var-size=20000000 -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-lgomp -lpthread

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f"
    @echo Compiling .\riod.f
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\riod-mp.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -static -fopenmp -m32 "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC

The other issue I am having is probably not a SF issue but hoping someone has a clue what is going on. The above mentioned program uses OpenMP for parallel processing. My development system has several instances of this code running at any given time. When I built a new version, I noticed the performance was bad. After testing, I noted that even though I am requesting multiple threads in the executable, only one thread was being used. However, if I move the executable to a different folder and CMD window, it works with the specified number of threads. Even more maddening is that I can move to a different folder and use the same executable and it won't work again. I even used the CMD window in a folder that doesn't work and changed directories to where it was working and restarted the program and it still works there. It seems to be a directory issue but I can't find differences.

Thanks in advance.

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

The most common cause for "not a valid Win32 application" is oversized statically allocated arrays.  I notice from the makefile that you're compiling a 32-bit executable.  I would suggest the simple step of switching to 64-bit (if you're on 64-bit Windows) to see if it alleviates the problem.  A quick Clean and Build should tell you if it fixes the issue.

I would suggest upgrading your Simply Fortran instance, though.  You can just download and install 2.41 over 2.30, and it might result in better performance.  Simply Fortran 2.30's OpenMP implementation relied on a Windows pthreads wrapper for OpenMP, but modern versions of Simply Fortran use native Windows threading, which should be mildly faster and eliminate the dependency on the pthreads DLL.  The DLL dependency might be the reason why it isn't working in some instances if the system-wide path to the pthreads DLL isn't properly set (Simply Fortran should have done this back then, I believe, but I'm not sure...).

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Thanks Jeff,

First I did test a 64 bit compile and it too fails with the same OS message. Then I upgraded to 2.41 and tested both 32 and 64 bit variants after recompiling. Again the OS rejects both of those executables.   

Does this mean that your assertion that oversized static arrays may not be the issue? I was going to ask how to manage those but now that may not be the case.

Rod

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

No, the static arrays may still be the issue.  Do you have any static arrays that are exceptionally large?  Even in 64-bit mode, there is a Windows-enforced 2GB limit (with additional the compiler flag -mcmodel=medium) on the total static array size.  The sum of all memory required by statically allocated arrays cannot exceed 2GB.  The limit is lower without the addition of the flag above.  If you need larger arrays, you would need to use dynamic allocation instead with Fortran's ALLOCATE statement.

I notice, though, that you're using a number of optimization flags and the fmax-stack-var-size flag.  I would start by disabling all of the optimizations and removing any compiler flags.  Clearly some step in compilation is causing the executable produced to be bad according to Windows, and eliminating the optional optimizations and flags would be a good start to diagnosing the issue.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Jeff,

I have not changed any of the array sizes, only added the duplicated subroutine to the code which seems to make the OS unhappy. The largest array I have (three of these) is 4000x1000 double precision, so what is that 8x4million bytes?

Removing the compiler optimization does not change the OS negativity.  Removing the fmax-stack-var-size flag does not cause the OS to complain, however executing the program I get a "Riod.exe has stopped working" pop up message. As I recall I needed that flag added make the program work.

Rod

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

If the executable actually runs without that flag, it appears that it is the problem.  Have you tried turning on Runtime Diagnostics (in the Project Options window under the Fortran tab) when not using the fmax-stack-var-size flag?  You'll need to clean and build your project again after enabling diagnostics.  It should catch any array bounds violations that might be causing Riod.exe to crash.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

I have done that but I see no indications from the compiler that there are problems; it compiles normally. I still do get the "Riod.exe has stopped working message". I set up the code to run launched from the SF GUI and it just crashes.

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Under Project Options, you need to enable "Runtime Diagnostics" in the Fortran tab.  This will catch errors while your program is running as opposed to compile time.  Bounds errors will not be caught by the compiler, generally speaking.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Yes, I have set the runtime diagnostics and as I noted there is nothing that happens other than the program crashes. There is no output to the screen or SF console window other than OS pop-up screen indicating the program has stopped.

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

I would recommend running it within the debugger in that case.  The debugger should stop where the program crashes.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Ok, I explicitly turned on debugging and rebuild. When I start the debugging session I get a SF debugging pop-up that says "Signal received: SIGSEGV - Segmentation fault". This happens a couple of times and then I get the OS message that the program has stopped. Nothing appears on the console. I have enabled profiling but when I check the profile it says, "Profiling data does not exist yet..."
Here is the current makefile:

#
# Automagically generated by Approximatrix Simply Fortran 2.41
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f


OPTFLAGS= -mtune=broadwell

SPECIALFLAGS=-m32 $(IDIR)

RCFLAGS=-O coff -F pe-i386

PRJ_FFLAGS=-fopenmp -fmax-stack-var-size=20000000 -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-lgomp -lpthread

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f"
    @echo Compiling .\riod.f
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\riod-mp.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -static -fopenmp -m32 "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

The program crashes when the Segmentation Fault occurs.  In the Debugger panel under "Stack" (it defaults to "Variables"), what is the position showing when the Segmentation Fault occurs?

Additionally, based on your makefile, I see no sign that debugging was enabled.  Can you check that again?  The -g flag should appear in the makefile. 

Profiling won't provide any useful information.  It would only be useful for seeing which routines take the most amount of time to execute with a long-running program.

Jeff Armstrong
Approximatrix, LLC

13 Reply by grogley (edited by grogley 2018-08-29 08:38:21)

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Ok, I have not used debugging in a while and it took me some time to poke around to find the Debugger stack. What appears in that window is the following:

MAIN_
_chkstk_ms 

This message disappears after the program terminates. Forgot to add the makefile:

OPTFLAGS= -g -pg

SPECIALFLAGS=-m32 $(IDIR)

RCFLAGS=-O coff -F pe-i386

PRJ_FFLAGS=-fopenmp -fcheck=all -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-lgomp -lpthread

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f"
    @echo Compiling .\riod.f
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\riod-mp.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -static -fopenmp -m32 -pg "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Can you try adding the flag:

-mcmodel=medium

to the Fortran and Linker flags boxes in Project Options under the "Compiler Flags" tab?   I think that should increase the stack size enough to avoid the crash.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

I tried adding the -mcmodel=medium flag but the program still crashes before debugging can start. 

Also, as I was playing with another version of the this code, I am trying to convert it to F90 format, I noticed that even when I backed out of the changes I made in the code it would not run. While debugging this f90 version, I get a message that states I have a recursive function call. (I had to look up what that is and I do not intend to recursively call anything). So while playing with that this morning, SF crashed.

Then I began thinking, I didn't try to compile the old code with the new SF version I am using. So I backed out of the original code change, (deleted the subroutine I duplicated) and recompiled to see if I could get back to where I was before I updated SF. Unless I have the compiler option -fmax-stack-var-size=20000000, the code crashed immediately as noted above. With that compiler option, I can debug and again as with the f90 version above I get a recursive call message again before the crash.

During debugging after I step into the offending call,  but the next step takes me to some intermediate position within a completely different subroutine; this different subroutine has not even been called yet. The debugger should still be in that subroutine but I get put elsewhere and then the next step comes back to where is should be. This may be the real issue, that there is some sort of memory alignment issue?  Here is the makefile from this last test.

#
# Automagically generated by Approximatrix Simply Fortran 2.41
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f


OPTFLAGS= -g -pg

SPECIALFLAGS=$(IDIR)

RCFLAGS=-O coff

PRJ_FFLAGS=-fopenmp -mcmodel=medium  -fcheck=all -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-lgomp -lpthread

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f"
    @echo Compiling .\riod.f
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\riod-mp.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -static -fopenmp -pg "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC

Sorry to be such a bother, I fear my bad programing is somehow rearing its ugly head.

Re: File "is not a valid Win32 application" SF 2.30 build 2281

I am now trying to debug my old code for this recursive call error. Note that this code worked perfectly fine in SF 2.3 before I made changes. I have restored this as a 32 bit project and have the following as the makefile:

#
# Automagically generated by Approximatrix Simply Fortran 2.41
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f


OPTFLAGS= -g -Og

SPECIALFLAGS=-m32 $(IDIR)

RCFLAGS=-O coff -F pe-i386

PRJ_FFLAGS=-fopenmp  -fmax-stack-var-size=20000000 -fcheck=all -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-lgomp -lpthread

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f"
    @echo Compiling .\riod.f
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\riod-mp.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -fopenmp -m32 "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC


Debugging I go to the first call of the offending subroutine (sizeobj) and step inside. The debugger takes me to the subroutine definition line. The next step takes me to another uncalled subroutine "End" statement. The next step takes me back to the called subroutine and then the next few steps executes the simple calculations and exits back to the calling routine.

I jump to the next instance of sizeobj and step inside the routine. The next step now causes the program to crash. Here is the code for calling sizeobj the second time; note I have added the tmpxx variables to pass arguments to the sizeobj subroutine and it does behave slightly differently this way:

implicit real*8 (a-h,o-z)
...
        tmp10=sm(j)
        tmp11=con(56)
        tmp12=0
        call sizeobj(tmp11,tmp10,tmp12)
        sz(j)=tmp12

Here is the simple subroutine being called:

      subroutine sizeobj(factor,zmass,radx)
      real*8 factor,zmass,radx
c
       radx=factor*(zmass**(1.d0/3.d0))
      return
      end Subroutine

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Have you tried running everything without OpenMP enabled?  Your program should run fine without it, and it eliminates another possible source of a problem.

You also mentioned that the calls are "recursive," but I don't see where any recursive calls are being made.  Recursive subroutines must be declared as such:

       RECURSIVE SUBROUTINE SIZEOBJ(factor, zmass, radx)

Also, your sizeobj subroutine is just screaming to be converted to a function, which might help (though I still don't know why you're seeing a crash).  Could you change it to:

function sizeobj(factor,zmass)
      real*8 factor,zmass,sizeobj
c
       sizeobj=factor*(zmass**(1.d0/3.d0))
      end function sizeobj

and change your call to:

    sz(j) = sizeobj(con(56), sm(j))

Perhaps, though, you've simplified things for us, and we're not seeing some additional work being done.

I am worried, though, that something may be wrong with the stack just because OpenMP is enabled.  It would be a new bug if so.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Jeff,

I had tried changing the subroutine to a function in the f90 code but not my legacy code. I have been cleaning up this code since this episode to make it more modern (got rid of my old do loops and number continue lines) and so doing this change was not a big deal. It didn't make any difference though as the code still has the recursive calls to nonrecursive procedure.

However, as you suspected, turning off OpenMP and removing the flags in the compiler options did make the code run.

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

It looks like there may be some odd stack behavior with OpenMP on Windows. You can try two things:

1. Set the variable [pre]OMP_STACKSIZE=256M[/pre] or something similar.  It should force any additional threads to start with a somewhat sizeable stack size

2. Use ALLOCATE to create all your arrays rather than pre-defining their sizes.  I'm guessing that you might be hitting some sort of per-thread stack size limit that isn't quite working right.  That would be a bug on our part, of course.  I'll look at the OpenMP library code to see what's wrong.  But allocating everything might possibly be a workaround.

Sorry for all this trouble!   As programs get more complex, so do the possible problems.

Jeff Armstrong
Approximatrix, LLC

20 Reply by grogley (edited by grogley 2018-08-30 14:30:32)

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Jeff,

One thing I should have mentioned is that the recursion error occurs long before any OpenMP directives  are initiated. I do have some calls early on to determine the number of processors and to set up home many to use, but only one thread is active.  This part of the code is all single threaded.

Not sure exactly if I did this right but I added the line:

!$      OMP_STACKSIZE=256000000

to the top of the code. The compiler didn't barf on this line of code and compiled without error. Running the code with OpenMP enabled and the result is pretty much the same as it fails to run.

Since none of the arrays in this code have changed from the version I was using with SF2.3, doesn't that mean that my code as is should run under SF2.41 (Specific bugs in SF2.41 notwithstanding)? If that is the case, I am loathe to change too much in the code at this time if there can be a fix for the problem. I looked into the allocated arrays and not sure I completely understand how to make the changes and as it touches  many things routines in the code. I will investigate this more however as if it can alleaviate issues going forward it may be worth doing.

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Jeff,

I am just wondering if you were able to determine if there was some issue with the OpenMP stack and if there is a fix for it? I am still trying to figure out how to change my code to do the array allocations. I am still debating the best way to implement the code changes. An easy fix would be to make all the arrays static and allocate the memory as such but I don't see how that is different that what I currently do. I may try this in a week or so.

Thanks,
Rod

  • jeff
  • Administrator
  • Offline

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Simply Fortran's OpenMP implementation on Windows apparently ignores OpenMP stacksize directives.  The stacksize will default to Windows' 1MB  size.  You can change this in theory using the following flag in the Linker box under Compiler Flags in Project Options:

-Wl,--stack,N

where N is the number of bytes for the stacksize.  Other than that, there shouldn't be any problem in theory with OpenMP.   While you're in the Project Options window, though,make sure to remove all references to Pthreads.  Simply Fortran's  OpenMP implementation does not require or use Pthreads any longer (it did in 2.3), and the Pthreads library could be doing something weird at startup.

If you're using static arrays still, have you determined or guessed at how much memory you're using?  I haven't seen much about the memory requirements for your program, though I suspect the issues are still related to threading since the program works with OpenMP disabled.

Jeff Armstrong
Approximatrix, LLC

Re: File "is not a valid Win32 application" SF 2.30 build 2281

Jeff,

I am just getting back to this as I was away since my last note.

With the changes to the compiler options you gave me, I can now run my program in OpenMP mode.  I am using the converted FORTRAN 90 as 64 bit source for my testing as I would like this code to become the default code going forward. Note that all my arrays are still static. You asked about array sizes, I reported that in one of these earlier communications but I was wrong. I have 3 large arrays of double precision reals that are 12x1000x4000 which is over a Gigabyte for all three if my arithmetic is correct. Three are other smaller arrays but none that compare to those three.

Questions: the number of bytes in the -Wl,--stack,N option, is that for the entire executable or for the largest array size?

I am having somewhat perplexing run time use of CPUs that I am trying to understand. For example, when running a modest sized problem using all possible threads, the CPU only goes about 67% busy. The CPU use will increase to about 90% if I triple the size of the problem. I never got this type of behavoir before on the old 32 bit code. On the 32 bit code, only for very small problems and large thread numbers would the CPU use be inefficient.

Here are the linker options I am currently using (There are no compiler options specified at this point).

-Wl,--stack,1500000000 -lgomp

And here is the Makefile:

#
# Automagically generated by Approximatrix Simply Fortran 2.41
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f


OPTFLAGS= -O2 -fgraphite-identity -floop-interchange -floop-strip-mine -floop-block -floop-parallelize-all

SPECIALFLAGS=$(IDIR)

RCFLAGS=-O coff

PRJ_FFLAGS= -fopenmp

PRJ_CFLAGS=

PRJ_LFLAGS=-Wl,--stack,1500000000 -lgomp

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\riod.o": ".\riod.f90"
    @echo Compiling .\riod.f90
    @$(FC) -c -o "build\riod.o" $(FFLAGS) ".\riod.f90"

clean: .SYMBOLIC
    @echo Deleting build\riod.o and related files
    @$(RM) "build\riod.o"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting riod.exe
    @$(RM) "riod.exe"

"riod.exe":  "build\riod.o" "build\Riod-MP-F90.prj.target"
    @echo Generating riod.exe
    @$(FC) -o "riod.exe" -static-libgfortran -fopenmp "build\riod.o" $(LDIR) $(PRJ_LFLAGS)

all: "riod.exe" .SYMBOLIC

Rod

Re: File "is not a valid Win32 application" SF 2.30 build 2281

I want to follow up to this thread and sort of close it out. I spent the last several weeks thinking about my issues and trying figure out how to use allocated arrays. I finally hit on that my three really large arrays are only used in one subroutine and I thought it would be easy to set up the array allocation for those three arrays. A few simple changes resulted in an executable that was much smaller and used only the memory for those arrays that we needed. Of course my initial elation at the reduced memory footprint and significantly reduced execution time were tempered with some ill behaviors which I eventually fixed.

What is still disappointing is that the 32 bit code will not run, even with the new memory allocations and reduced footprint. However, since I am moving on to more modern code, the 64 bit version will be the default going forward.  Thanks for the help.