Help with C/C++ and FORTRAN project

[jdc5011]

I am attempting to compile a C/C++ program that leverages functions from a Fortran library using Intel Visual Fortran Composer XE 2011 SP1, with Microsoft Visual C++ 2010 and RTX SDK 2011. This program is intended to run on a Windows 7 32-bit OS with an RTX 2011 runtime environment. Interval Zero (who maintains the RTX SDK) does not explicitly support Fortran programming; however, in the past we have been successful using the Compaq Visual Fortran Standard Edition 6.6A with Visual Studio C++ 6.0 and RTX SDKs up to and including RTX 8.1.2. Because the target runtime environment for the resulting executable is real time, I am forced to exclude the default libraries from the C/C++ program. After I started having trouble with my large program, I decided to write a simple little test program. This program will generate the same link time errors that my large program generates when I exclude the default libraries.

My testing solution consists of four files (1 .h, 1 .c, 1 .fi and 1 .for) and contains both a C project as well as a Fortran project. The Fortran project builds a static library, which I then link into my C project. The four files are included below in their entirety:

RTTestApp.h

#include

#include

#include

#ifdef __cplusplus

#define EXTERNAL extern C

#else

#define EXTERNAL extern

#endif

void __stdcall cfs_write_message(char *message,long msg_len);

RTTestApp.c

#include RTTestApp.h

extern void FORTRANTEST();

void _cdecl main(int argc,chac **argv,char **envp)

{

printf(Calling FORTRAN\\n);

FORTRANTEST();

printf(Back from FORTRAN\\n\\n);

ExitProcess(0);

}

void __stdcall cfs_write_message(cahr *message,long msg_len)

{

char c_message[256];

memcpy(c_message, message, msg_len);

c_message[msg_len] = \\0;

// Write message to the screen

fprintf(stdout, %s\\n, c_message);

} // end function cfs_write_message

MainFortran.fi

interface

subroutine cfs_wirte_message(message)

!DEC$ ATTRIBUTES STDCALL, REFERENCE :: cfs_write_message

character*(*) message

end subroutine cfs_write_message

end interface

MainFortran.for

subroutine FORTRANTest

implicit none

include MainFortran.fi

character*256 string1,string2

character*32 string3, string4

character string5

call cfs_write_message(Doing some Fortran strings)

C This line will fail to link because it cannot resolve _for_cpystr

string1 = Hello World

C This line will fail to link because it cannot resolve _for_cpystr

string5 = Hello World

C This line will link properly

string3 = Hello World

C These lines will fail to link because it cannot resolve _for_concat

string3 = Hello

string4 = World

string1 = string3 // string4

C This line will link properly

string3 = Hello // World

C This line will fail to link because if cannot resolve _for_concat

string3 = Hello // // World

C These lines will fail to link because it cannot resolve _for_cpstr

string3 = Hello

string4 = Hello

if(string3 .eq. string4)

call cfs_write_message(string1 and string2 are equal)

else

call cfs_write_message(string1 and string2 are equal)

endif

return

end

I am not having compile errors. I am simply getting unresolved externals when I attempt to build the C project with the Fortran library linked in and I exclude the default libraries. When I include the default libraries, I do not get any compile or link errors, however I get an executable that Rtssrun.exe cannot execute. What I am looking for is an answer to whether it is possible to do anything with Fortran strings without the default libraries and if so how can I make it work, or if we have to go another direction. I have noticed that when I use different combinations of optimizations/floating point models on the Fortran side I am able to eliminate some of the unresolved externals such as the trig functions sin/cos/tan etc. I believe that this is due to the compiler deciding to replace the external call with something faster. I mainly saw this when I was working with trig functions or doing real*4/real*8 math. If there is a combination of settings that will force the FORTRAN compiler to replace the external string functions (_for_cpstr, _for_cpystr, _for_concat etc..), I have not been able to find it however, I have only been programming on a large scale for a short time now and this is the first major program Ive worked on that uses both C and Fortran.

[Steven_L_Intel1]

You need to resolve those routines from the Intel Fortran library libifcoremt.lib. There is no compiler option to eliminate these calls.

[jdc5011]

I had a feeling that was the case. Unfortunatly, when I do include the libifcoremt.lib, the rsulting executable is no longer usable in the real-time environment. Just out of curiosity, any thoughts as to why it worked with CVF?

[Steven_L_Intel1]

With CVF you needed to supply __OtsMove and __OtsFill. Intel Fortran uses different routines for these functions. Whatever you did to resolve the references to the CVF routines needs to be duplicated for use with Intel Fortran.

[jimdempseyatthecove]

Quoting Steve Lionel (Intel)

You need to resolve those routines from the Intel Fortran library libifcoremt.lib. There is no compiler option to eliminate these calls.

Steve, is there the equivilent of function prototypes available such that this user can produce his own replacement functions?

jdc5011, check to see if you can us the librarian to extract the missing functions from the static redistributable library (Cannot say if the License permits this). Once extracted (and any dependencies from those extracted), you can see if any of the extracted functions make RT unsafe calls. If they do then the subset of those functions that make the unsafe RT calls can then be rewritten (as opposed to all). I think the string copy example will be safe, excepting for calls to invalid args etc... but those can easily be replaced with other code.

Jim Dempsey

[Steven_L_Intel1]

We do not provide documentation or interfaces to the Fortran library's code support routines. But for these it should not be difficult to deduce the interface from an examination of the assembly for the call.

[mecej4]

I don't see why this issue has to be a stumbling block for someone who has undertaken a rather special task such as writing a program to work with a real-time-executive.

We have not been told why a program with dependency on libifcoremt.dll fails to work with the RTE.

However, the only routines at issue are _for_concat and _for_cpystr. Writing replacements for these functions in C or assembler is a nearly trivial task.

[Steven_L_Intel1]

I assume that one is linking to the static libraries, not the DLL.