Case of names when linking against Visual Studio C on windows

[k_m_buckley]

Hi there,

I have recently come into the development of a Fortran code upon
windows, a code which is to be compiled for use as a plugin/DLL for
use with the Stata package, here at the Centre for e-Science at the
University of Lancaster, UK.

Compiling a standalone verion of the Fortran code on windows
using W_FC_C_9.1.028 gives no problems but trouble surfaces
when the linking against some C interfaces required to talk to
Stata, the C code being compiled with Visual Studio's C
compiler. (All this in a DosBox by the way, no GUI for me)

At first I was thrown by the fact that linking with ifort
was telling me it couldn't find, eg, _CD_READOB when I knew
there was a procedure cb_readob in the C interface and that the
plugin had been created successfully on Lancaster's HPC system.

I finally discovered -Qlowercase, /names:lowercase but then
found that the ifort linking could now not resolve the
external symbol _flush which was being called in the Fortran.

OK, here is what I think is happening: when I compile standalone,
everything is promoted to upper case and the call flush is
resolved against a symbol in the Intel Fortran library that
is uppercased, however if I explictly lowercase the symbols
in the Fortran code, so as to match the C code interface, I am
goosed because the symbols in the Intel Fortran library are in
uppercase.

It is not my code; I'd rather not be on the windows platform and
although I have ways round it, I'd rather not eg, add a swathe of
preprocessing directives to the code just to get it compile for
windows - suffice to say, we have seen no problems using Intel
Compilers on Lancaster's HPC platform when building a plugin for Stata
there, though we are using the Intel C compiler as well there so
we were quids in to start with by virtue of at least using the
same manufacturer's compilers for mixed language programming.

Any thoughts/experiences ?

Kevin

PS
I did think about (but not look into how to) promoting the symbols in
the C code to be uppercase assuming there is such an option to the
Visual Studio C compiler but I reckon that's opening a can of worms
which has "DO NOT OPEN" written on the side. (and yes, there's an
uppercase pun there)

[Lorri_M_Intel]

First thing --- may I suggest that you look at the chapter on Programming with Mixed Languages in the online documentation. There are a number of interesting things to keep in mind when interfacing Fortran and C, including (but not limited to!) how numeric arguments are passed, how character arguments are passed, array representation, etc.

You mentioned "linking against some C interfaces". Does that mean that you're just making calls to the C routines from within your program? Or, do you have some actual INTERFACE/END INTERFACEdefinitions for these routines? If you don't have that, again, I'd suggest you do it. That would help head-off problems with the mixed language interfacing. At the very least you should declare that the external routines as C routines, so that the proper argument passing is done.

Finally - you're mostly right about the "flush" issue. I assume you have a statement that looks like "CALL FLUSH" in your program, and yes, when the external name is generated with the leading underscore and in uppercase, it gets resolved in the Fortran RTL. However, one might argue that you were lucky here. Things that we know are going to be RTL routines, we generate the correct external name always. We don't know that you absolutely meant for our version of FLUSH to be used -- maybe you'd written your own? We didn't know. To tell the compiler that you want to use our version, add the line

USE IFPORT

to the program unit that has the CALL FLUSH. That module has an interface block defining the correct name and signature for the RTL flush routine. It will resolve the unresolved external, and you won't need to have a bunch of conditional compilation for Linux vs Windows.

- Lorri

[TimP]

Lorri is correct, if you look up FLUSH in the ifort docs, you will see that it is still treated as a non-standard portability function, requiring the USE IFPORT. This really ought to be fixed soon, as FLUSH has been a Fortran standard intrinsic for several years now.

[Steven_L_Intel1]

No, FLUSH is not a standard intrinsic. It IS, however, a standard statement and our compiler supports FLUSH as a statement.

[Mark_Westwood]

Kevin

You might want to look for the ISO_C_BINDING intrinsic module which is coming in with Fortran 2003. Intel Fortan 10 implements this, I don't know if v9 does or not. I find it quite useful in writing Fortran routines which look, to the outside world, a lot more like C routines. Using this approach you have a language-standard way of integrating codes, rather than having to rely on compiler switches and the like.

Regards

Mark Westwood

[Steven_L_Intel1]

ISO_C_BINDING (and the BIND(C) attribute) were new in 10.0.

[k_m_buckley]

Cheers all for the replies - most illuminating!

Firstly, there are no INTERFACE/END INTERFACE blocks relating to
this issue.

The person responsible for dragging the original Fortram source to something close to Fortran 90 has gone some way down this route but as it stands, the
code is a mix of well, think of a Fortran and some part of it is probably in
there.

The interfaces I refer to are more of a "interface as gateway" through
which our code can talk to the Stata package, basically a few callbacks
and procedures for shipping data around between us and Stata.

Secondly I have jumped through mixed langauge programming hoops
before, otherwise I would not have even started on this !

As to the use of USE IFPORT, I saw this in the docs but given that such a soultion would only be needed for the windows environment, there seemed
to be little to be gained by adding it and then having to wrap in it a
preprocessor macro so as to keep the code the same across platforms,
as I have already needed to do for certain procedures.

(Probably worth pointing out here that although I have a sci-programming
background I moved sideways into being a UNIX Sys Admin for the past
twelve years or so, and picked up a whole swathe of "good things and knowledge", so take it as read that some of my use of the M4 preprocessor
to munge the Fortran code I was presented with is not something the current developers seemed that quick to get a handle on - I am therefore trying to limit the usage of such devices where I can. I am also off at the end of the month
and this (plugin/DDL on windows) has all been dropped on me in the last
two days and I am keen to not make things too complicated for those who
continue to work on it)

One of the other developers is aware of the benifits to be gained once the
Fortran 2003 stuff starts to appear but for now he will probably look to
simply get the code to be "real" Fortran 90.


Cheers again for the repsonses,
Kevin

[Lorri_M_Intel]

For what it's worth, while USE IFPORT is not necessary on Linux to resolve the naming issue, it certainly doesn't hurt. No conditional compilation required.

[g_f_thomas]

With a module definition file (.def) you can have full control over your dll exports.

Gerry