I use a small in-house cluster (approx. 31 machines) to help complete parallel runs of a numerical groundwater model. After the groundwater model completes, a short post-processor manipulates some data for use by a code that is collecting output from the parallel runs. It used to be that the post-processor, written in fortran and compiled using intel's visual fortran from inside Vis. Studio 2010, was distribute-able, meaning I could place the .exe in amongst the other files that were distributed across the cluster and run on the various machines. Now, however, if I compile the very same fortran using visual studio 2012 with Intel Fortran XE 2013, I get an error on the cluster machines stating, "The program can't start because MSVCRR110.dll is missing from your computer. Try reinstalling the program to fix this probelm."
One of the reasons I like using Fortran is that it used to be self-contained. In other words, if I wrote small programs to do some short pithy task in another language, say R or Python, then I have to either install these programs on all the cluster machines or else "sandbox" the programs in with my distributed files. Forget about trying to use C# or VB etc., because then the cluster machines would need to have .NET framework installed. For the time being I can go back and use VS2010 to compile, but I don't anticipate having this option available to me much longer. Is there another alternative for keeping fortran programs "self-contained" in VS2012? As you can see in the code below, nothing complicated and no reason for it not be a self-contained executable:
program Calc_Seep
implicit none
! Variables
integer reason
real wp,time,ft,fts,fr,fo,fst,fro,loss1,loss2,loss3
character (len=120) line
character*50 txt
character*20 fmt
wp = 9.38 !a needed constant value
!read(*,*) txt
open(5,file='balance.out')
read(5,'(A)') line
do while (.NOT.line.EQ.'')
read(5,'(A)',IOSTAT=Reason) line
if (Reason < 0) exit
end do
read(line,*) time,ft,fts,fr,fo,fst,fro
!acre-ft/mi/yr
loss1 = (ft/time)*0.3048*5280*208*24/(0.3048**3)/43560.17
!ft/day
loss2 = (ft/time)*24/(0.3048**2)/wp
!cfs/mi
loss3 = (ft/time)*24/(0.3048**2)*5280/86400
close(5)
!now write the processed values to a file
open(5,file="Seepage.out")
write(5,'(A)') "acre-ft/mi/yr ft/day cfs/mi"
write(5,100) loss1, loss2, loss3
100 format(3f13.6)
close(5)
end program Calc_Seep
This is simply a change in default project properties for newly created projects. As of Intel Visual Fortran Composer XE 2013 SP1 (compiler version 14), the default is to link against the DLL libraries, matching what MS Visual C++ does. Existing projects are not affected and you can still change the libraries setting (Fortran > Libraries > Runtime Library) to "Multithreaded" from "Multithreaded DLL". If you do that, then it will again link to the static libraries, though there are some libraries provided only in DLL form (OpenMP and coarray support).
Related
I'm using Intel Fortran Compiler 15.0 within the Visual Studio 2013 environment. I'm new of those softwares and I'm not a programmer, but just an engineer using fortran to do some computation, thus, please, try to reply with an "easy" language.
The problem is this: I'm in the debug mode and I compile and execute the program within visual studio just pressing "start debug". Everything goes fine and I get what I expect, still the code run slow. Now if I go to the folder .\x64\Debug and run the program from the executable file, it gives different results (and at certain points stops due to unrealistic results). What is happening? I have no idea of how to fix it. Why is it working fine within visual studio and crashes if run from the executable file? The executable file created in Release mode gives the same problem.
Any help will be appreciated,
thanks a lot,
Antonio
I am pasting the answer that was given by the OP, since it was written as an edit (now removed) to the question rather than in an answer:
"I found out that the problem was in the allocation and initialization
of a logical variable. In the first place I had just allocated the
variable and I could see its value was .TRUE. after the allocation,
during debugging. Unfortunately, the allocation seems to work
differently if run directly from the executable file outside VS or
within VS. Adding "_NO_DEBUG_HEAP=1" to the environment causes the
behavior of the program to be the same inside and outside VS, thus I
could debug the code and I noticed that after the allocation the value
was .FALSE.. The problem was solved inserting a line just after the
allocate() command that initialize always the logical variable to
.TRUE.. Now I get the same results both inside and outside VS. This
post helped a lot Differences between running an executable with Visual Studio debugger vs without debugger
Thanks, Antonio"
I'm trying to build a program from its source code with VC 11. When the compiler is about to finish, it raises the error mentioned in title of this post.
As I've read here and in other forums, I tried to both close as many programs as possible and enlarge the size of the swap file in Windows... neither works.
I've read about a parameter called \Zm but I don't understand how to use it.
Can you please help me?
Take a look at this documentation which gives possible solutions:
I also had that problem and found the documentation useful. Main points:
If the compiler also issues errors C1076 and C3859, use the /Zm compiler option to lower the memory allocation limit. More heap space
is available to your application if you lower the remaining memory
allocation.
If the /Zm option is already set, try removing it. Heap space might be
exhausted because the memory allocation limit specified in the option
is too high. The compiler uses a default limit if you remove the /Zm
option.
If you are compiling on a 64-bit platform, use the 64-bit compiler toolset. For information, see How to: Enable a 64-Bit Visual C++
Toolset on the Command Line.
On 32-bit Windows, try using the /3GB boot.ini switch.
Increase the size of the Windows swap-file.
Close other running programs.
Eliminate unnecessary include files.
Eliminate unnecessary global variables, for example, by allocating memory dynamically instead of declaring a large array.
Eliminate unused declarations.
Split the current file into smaller files.
I can't tell much about the /Zm parameter, but I had the same issue (compiler is out of heap space).
What has helped me was the /m:4 (4 for the count of your CPUs) parameter so that you can use multiple CPUs for building.
Hope that helps you as well.
Also, if you are running on x64, be sure that the x64 version of "msbuild.exe" and "cl.exe" is beeing used. I had the issue that even when using e.g. the x64 ms powershell, the compiler would still choose the 32-bit version of msbuild.exe (in task manager "msbuild.exe*32", windows 7)
In addition to the other answers here (and in my case), fatal error C1060: compiler is out of heap space can be caused by a syntax error. The following code (in certain circumstances) can cause this error even with correct compiler options -- for instance if you've previously successfully compiled the same program.
r.push_back(e[1];
instead of
r.push_back(e[1]);
It seems to only cause this error rather than the standard error C2143: syntax error: missing ')' before ';' when r and e are of certain types, but it's worth checking any code you've edited recently if the program previously compiled without errors.
We had similar problem: a relativelly simple program (although, full of templates, using Eigen library) persistently failed to compile on one of the computers. All were using MSVC2013 x64, but only one was unable to compile the program due to C1060 error. We tried different compiler flags, setting/unsetting -Zm, but failed to resolve it without modifying code.
Some pointers were, however, given to us, when we switched from x64/x64 (64bit compiler for 64bit resulting executable) version of the compiler to the x86/x86 (32bit compiler for 32bit resulting executable). The x86 compiler gave us exact locations of the problematic parts of the program - calls to template functions receiving heavy templated objects. We have rewritten those to normal functions (build in different object file) and that solved the problem...
VS: Visual Studio 2015
OS: Windows10
If you are using VS2015 as your IDE, maybe there is another solution:
Go to update the VS2015 "Update3" package and everything will work smoothly.
In my case, a main program would not compile is VS 2022 Community Edition (free). It had many include files. By process of elimination, I managed to compile it once I removed any "volatile" modifiers in declarations that had this modifier.
A very strange bug, to say the least!
I got this error when compiling OnnxRuntime with MS Visual C++ 17 2022.
The solution for this issue was to close all other programs and compile using a single thread (in this case, removing the --parallel argument from the build.bat call).
I was trying to make my program accept input without the user having to press enter, so I tried the following:
mov ah,01h
int 21h
But it just crashes my program over an unhandled exception. This seems to be the way to do it according to much that I have read, so why isn't it working for me?
Now, I am fairly new to this language so I still do not exactly understand the process of how this piece of code works, so I would also appreciate what the logic is behind accepting input by pressing enter and accepting input without the user having to press enter.
MY OS is Windows, by the way.
Your code looks like MS-DOS-era assembly. VS2010 doesn't support generating DOS executables, and modern versions of Windows (the 64-bit kind) don't support running them, either. Looks like you were going by some old book or site, one that was written in late 80'es-early 90's. Back at that time, assembly was way more relevant and marketable as a job skill. Not so much these days, although some assembly knowledge won't hurt.
Decide what do you want to learn. If you want to learn modern assembly (and target Windows), get some recent guidance. The techniques are quite different, and int21h isn't among them :) If you're indeed after DOS-era assembly, set up a DOS virtual machine with DOSBox, and find some old free assembler. Visual Studio 2010 won't help you here. The latest version of Visual C++ that generated 16-bit executables was v1.5x.
Specifically why does your program crash. Int21h was how MS-DOS exposed its applciation program interface (API). Windows doesn't support it for Windows executables - there are other ways of invoking the API. When you assemble with Visual Studio 2010, you end up with a Windows executable, not a DOS one, and there's no option to generate a DOS one. As for the Windows executables, they're not supposed to invoke interrupts at all - that's a crash condition.
You need to obtain a tool set that can generate 16 MS-DOS programs. These should run on DOSBOX, or on a Virtual PC with MS-DOS installed on it. Microsoft included 16 bit tool sets up to Visual C / C++ 1.52, but Visual C / C++ 4.0 and 4.1 also contain the 1.52 16 bit tool set. The older version of the compilers would be named Microsoft C 8.xx or earlier version. I don't know if any the early versions of Visual Studio (2002 or 2003) include the 16 bit tool set.
Use the linker version 5.60 to generate 16-bit DOS applications. You can get this from:
http://download.microsoft.com/download/vc15/Update/1/WIN98/EN-US/Lnk563.exe
Dirk
I'd like conditional compilation based on whether the compiling machine is running Windows 7 SP1 or not.
We have a workaround for http://support.microsoft.com/kb/2517589 but I don't want to check the code in unless it is guarded by an #ifdef _WIN7_SP1 otherwise the other devs won't be able to compile it on their non win7-sp1 machines.
I've had a bit of a google but couldn't find anything useful.
You don't. Things in the environment of the build machine generally don't pollute compilation like that. (Imagine if that happened and what effects it would cause on reproducibility of builds.)
If you really need to, I'd instead have your build system (make, Visual Studio, whatever) execute a program that checks the current Windows version and fails as necessary (or possibly your build system can determine this already). Based on that, you then could conditionally make own WIN7_SP1 definition via a command-line argument to your compiler.
I've always been curious as to how one extension, EXE, can be as versatile as it is in that if you assemble an assembly program, you get an EXE in machine code for your processor but if you compile a C# or other .Net program, you also get an EXE except that it is run in the proper runtime environment. I'm not sure if this is different from OS to OS (I imagine it is), but when an EXE is executed, how is it determined how to execute it?
On a related note, if I were writing my own programming language, how would I tie in my runtime environment into this mechanism?
When compiling a .NET program to an EXE, it's more than just a blob of bytecode (like Java). There's actually native executable created that will load the .NET runtime and hand off the .NET bytecode to it, or display a friendly-ish error message indicating that the framework is not available.
The format is even more flexible than that, as every Windows EXE actually includes a DOS program at the beginning which will display an error ("cannot run in DOS mode") when executed as a DOS program.
You can read more details on the PE format on Wikipedia: http://en.wikipedia.org/wiki/Portable_Executable