Fortran static library without the default libraries

[jdc5011]

Let me start by saying that I am very much a novice programmer so if I use incorrect terms please forgive me.

I am working on a major project which has been around for longer then I have. We recently upgraded our development are to MSDev studio 2010 with the Intel fortran 2011 XE compilers. We have a project (which we successfully upgraded from CVF using the wizzards provided). The project in its original format (last compiled with MSDev C++ 6 and CVF) consists of both C/C++ and fortran code. I have successfully broken the program into essentially two projects with the fortran code compiled into a static library which is then linked into the C/C++ project.

The problem that I am running into is that due to runtime limitations (mainly running under a real time sub-system) I am physcially restricted from linking W32 dll's so by default I have to set the disable default library flag to "Yes" in the fortran properties page. When I do this however, I get a clean compile, but I get a bunch of unresolved externals such as _for_exit, _for_concat, _for_cpystr etc. at link time. I can see that some of these methods are coming from the ifcore.lib (or one of the many provided ifcore.lib's), and I have been doing research to see if there is a way to find out the implementation of these functions, but everything I have found online simply says to include the default libraries, which as I stated earlier I cannot do. Am I up the creek without a paddle so to speak or is therea way for me to determine the implementation of some of these functions so I can write some C code to emulatethem without haveing to link W32 dll's at runtime?

As a side note, I have succesfully built a standalone project consisting of the same code, more or less,but intended to run in a non-realtime environment (which allows me to then include the default libraries for the fortran) and it compiles and runs as expected.

[Steven_L_Intel1]

Sorry, there is no public documentation on these routines, but you should be able to build an application that does not reference Windows DLLs if you are careful. Have you tried simply adding ifcore.lib to "Additional Dependencies" in the linker tab and see if you get everything satisfied without DLLs?

[jdc5011]

I have triedspecifyingifcore.lib on the includedlibrariesand unfortunatlly it generates an unusable executable. Thank you for your response. Looks like I have a lot of work ahead of me.

[Steven_L_Intel1]

What is the full list of _for_xxx routines that are referenced?

[IanH]

Quoting jdc5011

...
The problem that I am running into is that due to runtime limitations (mainly running under a real time sub-system) I am physcially restricted from linking W32 dll's so by default I have to set the disable default library flag to "Yes" in the fortran properties page. When I do this however, I get a clean compile, but I get a bunch of unresolved externals such as _for_exit, _for_concat, _for_cpystr etc. at link time. I can see that some of these methods are coming from the ifcore.lib (or one of the many provided ifcore.lib's), and I have been doing research to see if there is a way to find out the implementation of these functions, but everything I have found online simply says to include the default libraries, which as I stated earlier I cannot do. Am I up the creek without a paddle so to speak or is therea way for me to determine the implementation of some of these functions so I can write some C code to emulatethem without haveing to link W32 dll's at runtime?

"physically restricted from linking W32 dll's"? What does that mean?

Are you talking about not dynamically (runtime) linking to the fortran runtime library dll's? If so, then does static linking help? (Set the property Fortran > Libraries > Runtime library to Multithreaded or Debug Multithreaded as appropriate, additional steps required if you are using OpenMP)

Or are you talking about something else (The Win32 system DLL's? The Fortran library lib files?)?

"unusable executable"? What does that mean?

[jdc5011]

the full list of unresolved externals is:

_for_cpystr
_for_emit_diagnostic
_for_concat
_for_cpstr
_for_len_trim
_for_f90_scan
_for_stop_core
_for_f90_index
_for_read_seq_lis
_for_read_seq_lis_xmit
_for_rewind

I uesd dumbin to examine the default .lib files contained in the compiler/ia32 folder. From what I can tell most of the string fortran routines come from one of the ifcore*.lib files. Now I can look at the output from dumpbin but as I mentioned earlier I am new to alot of this so most of doesn't make a lot of sense to me. I can see that ifcore.lib for example contains _for_cpystr, _for_concat and _for_cpstr. From what I can tell the ifcore.lib file simply poitns to a .dll where these functions reside. Is this not correct? From converting my old project I noticed that there were three libraries added to the included libraries list: dfor.lib, dformt.lib and dfconsol.lib. I did some research on this and it seems that these were digital fortran libraries that were part of the CVF installation and I have found ifconsol.lib (which I'm assuming is intel's version of the digital fortran consol library). Including this library by itself does not solve any of my problem at the moment.

The whole issue is the fact that we are intending for this executable to be run in a windows real-time subsytem (IntervalZero's RTX). RTX support C/C++ code but does not explicity support fortran. In the past we were able to determine that everything we were doing in fortran compiled down to either asembly language or calls toa runtime librarythat IntervalZero supported. Perhaps this is not the case anymore.

[Steven_L_Intel1]

You have I/O in there - you're not going to be able to avoid Windows DLLs with that. If you replace the Fortran I/O statements with calls to C routines that do your I/O, you'll get rid of some of these. You should also do a release build and not debug. You have string copies and concatenations that could be replaced with calls to C routines. Remove the STOP statement. LEN_TRIM and SCAN are string routines also replaceable with C code (you would have to modify your sources for all these.)