Hello,
I am trying to compile a windows executable of a CFD code that is mixed language – composed mostly of fortran file with a few c-files for memory allocation handling. The code is a legacy code that I am porting.
After the code files have been compiled and during the linking process, I get several “undefined reference to ‘filename_’” where filename is the name of the corresponding c-routine. Some of the file names have underscores in them, and hence I know it can be problematic with compilers, especial between c and fortran.
I am using the -Munix compiler flag in order to get around other problems already encountered during the compilation process.
I have tried using both -Msecond_underscore and
-Mnosecond_underscore compiler options, but neither solve the problem. I have tried manually appending an underscore to the function names as well.
What is the trick in PGI to get the automatic single underscore append to stop messing up the linking process. Perhaps someone could explain what the rule is for automatic appending underscore characters.
Thanks,
-Steven Speer
When programs are compiled with pgf90/pgf77 on UNIX or on Windows when the “-Munix” flag is used, a trailing underscore is appended to the end of function names in order to distinguish between the Fortran name space and the C/C++ name space. So when a Fortran program calls a C function, it assumes the C function name ends with an underscore.
One solution is to change the C function names by appending an underscore. Of course, this may cause problems for other compilers and hence not very portable.
A second is to add “C$PRAGMA C( foo )” to every Fortran subroutine that calls the C function. Replace “foo” with the actual function name. This tell the compiler that “foo” is a C function and not to add the under score. While more portable, if you call the C function from a lot of Fortran subroutines, it can be a bit of work.
A third option is to use define statements to change names of your C functions only if PGI is being used. For example in at the top of the c source or in a header file you would add:
#ifdef PGI
#define foo foo_
#endif
On the C files compilation line you would then add “-DPGI”.
Note that chapter 10 of our users guide gives more information about Inter-language calling conventions.
The flags “-Msecond_underscore” and “-Mnosecond_underscore” are for compatability with g77 which uses two underscores for Fortran function names.
Hope this helps!
Mat
Mat,
I ended up using condition compiler directives with a _PGI_COMPILER macro test in order to define the proper function name and prototypes (i.e. lowercase with underscore appended in order to be consistent with the -Munix option) and also the appropriate argument list so that my code would work with PGI.
The undefined reference problems went away using what you suggested. However the problem remains with the HOSTNM function, which I haven’t been able to resolve yet. Therefore I just commented out that routine until I can figure out what the problem is with C3F functions in PGI.
Thanks again Mat for your response.
I almost have all the problems converting to PGI worked out so I can finally test OpenMP. The current problem is related to timing routines that are in my code that use the native Windows API high precision timer routines QueryPerformanceCounter and QueryPerformanceFrequency. I am using these routines because I need timer resolution less than 1 second.
After successfully compiling and linking my code, when I run the code the timing routines output “-1.#IND00” which then results in “-nan” being outputed. I tried extracting the timing routines and testing them separately and they work fine. Curious? Perhap it is a problem communicating the results of the C function back to the calling Fortran routine. Like the address of the timing variable is being past instead of the actual value. I don’t know yet.
The code routines work fine using the Visual C compiler, but I still haven’t figured out PGI yet.
I must admit switching compilers is certainly not an easy straight forward task. All the suddle differences between compiler flags, include files and differences in available intrinsic functions, etc. make the test and evalution process more challanging. But from my experiences upto now migrating from one compiler to the next these types of problem are not surprising or unexpected.
So I will keep pushing ahead and hopefully resolve the final issues today so that I can run test cases over the week end.
–Steven Speer