Conference turris::fortran

How about F90?  See notes 35-37.

			Steve

>> F77 for Intel Windows NT

There is no "F77" for Intel/NT, never will be.  F90 is DIGITAL Visual Fortran
on Intel/Win32 {NT and Windows 95} and soon to be on Alpha/NT.

/Stan

Hi,

  Thanks for your quick feedback.

  I have been trying to use F90.

   I have a make file and application that F77 compiles and links on an Alpha
   NT system without any problems. I tried to compile and link using F90
   complier and ran into a few problems.

	1. In the makefile I execute the dfvars.bat file to setup the 
	   environment, but make must not "see" it because DF does not
	   execute.  So I compiled it by hand. That went OK.

	2. I commented out the compile in the make file so the link would
	   run. In the link I think I am missing a library it complains about
	   unresolved external symbols:

		__FIsqrt
		__FIexp
		_for_write_int_fmt
		_PARAMETER_MSG@8

  The last one is a call back into my C code, which works on the Alpha.
  The strange thing is that I have 4 other calls and it doesn't complain
  about them. I think it might have something to do with the undefined 
  symbol _for_write_int_fmt, but I am not a FORTRAN expert so I'm not
  sure. 

  Any help would be greatly appreciated!

Larry

    	Yes, it does look like you are not picking up the correct
    libraries.  How are you performing the link (exactly what
    command)?  The naming conventions on Intel are a bit different
    from Alpha (for things like _PARAMETER_MSG@8).  I would take a
    look at what the actual name is that is being generated in your
    C program and try to get things to match up.  You cannot,
    repeat CANNOT, have a different number of arguments to a routine
    in Fortran without, for example, experimenting with things like
    the cdec$ ALIAS directive.
    
    Cheers!
    Dave Eklund
    

>	1. In the makefile I execute the dfvars.bat file to setup the 
>	   environment, but make must not "see" it because DF does not
>	   execute.  So I compiled it by hand. That went OK.

    If at all possible, I'd like to see your makefile.  I often use nmake,
and haven't seen this before, so I'd like to find out (and fix ;-) ) this
problem.

>	2. I commented out the compile in the make file so the link would
>	   run. In the link I think I am missing a library it complains about
>	   unresolved external symbols:
>
>		__FIsqrt
>		__FIexp
>		_for_write_int_fmt
>		_PARAMETER_MSG@8
>
>  The last one is a call back into my C code, which works on the Alpha.
>  The strange thing is that I have 4 other calls and it doesn't complain
>  about them. I think it might have something to do with the undefined 
>  symbol _for_write_int_fmt, but I am not a FORTRAN expert so I'm not
>  sure. 

    As Dave explained in .-1, the standard Intel calling convention is to
"decorate" the routine names with a number indicating the number of bytes of
arguments.  You can get around this using aliases.  Do you want to share your
code, we can make suggestions?

	    - Lorri

>....... I tried to compile and link using F90
>   complier and ran into a few problems.
>	1. In the makefile I execute the dfvars.bat file to setup the 
>	   environment, but make must not "see" it because DF does not
>	   execute.  So I compiled it by hand. That went OK.

I think that you will find that this is because nmake uses the "exec"
model (unix) model for processes. Each command is a new process
creation. Thus when you execute dfvars.bat it takes effect for that ONE
command but not the very next one that nmake executes. The easy way
to handle this is to either:

  1. execute dfvars.bat BEFORE you invoke nmake (and thus the nmake
     command will inherit the variables)
     (this is the easy way and is the recommended way)
or
  2. Define each variable on the nmake command line as in
	nmake INCLUDE=C:\blah\blah\blh LIB=d:\blah\blah
     (this method is a real pain and not recommended)
or
  3. Place the appropriate definitions right in the make file as in
	LIB=C:\blah\blah
	INCLUDE=C:\blah\bleech
	PATH=c:\blah\bin;$(PATH)
     (this method is also not recommended because it doesn't allow tool
      selection outside the make file)

Lorri may tell us that there is another way to get this to work (since she's
been playing with this a lot) but I know the above methods will work at
least.

>	2. I commented out the compile in the make file so the link would
>	   run. In the link I think I am missing a library it complains about
>	   unresolved external symbols:

>		__FIsqrt
>		__FIexp
>		_for_write_int_fmt
>		_PARAMETER_MSG@8

First - make sure that you are using the DF verb to do the link and
NOT the "link" verb. "DF" knows that a .obj needs to be linked but it
also knows what libraries to use. As you have noted the first 3 are RTL
routines so you are just not pulling in the right libs. Using DF to link
should do that for you.

I'd like to clarify what my teammates have said regarding the last one.
When Lorri says "the standard calling method is to ...." what she means
is that the _STDCALL calling method (which goes by the name of "standard
call") as opposed to the "standard" as in "everyone does it this way".
Because, in fact, the "everyone does it this way" convention where "everyone"
is defined as "all C programs" (see reference "the world according to Bill
Gates :-)") is to use the _CDECL calling convention. You need to use
the same calling convention in caller and callee. This can be done
by putting directives in the fortran code to declare things as _CDECL
calling convention or by putting directives in the C code to declare
things as being _STDCALL. Either way will work but one way or the other
may be dictated by how much code has to be changed. Note that using
the !DEC$ ALIAS directive only fixes PART of the problem. It makes the
names match but does NOT make the calling conventions match and you will
run into problems with stack usage (since the different calling conventions
have different stack usages).
See the chapter on "Mixed Language Programming" for more details about
all of this.

As suggested by others, to properly answer your questions it would
be helpful to have more info (like your makefile, etc)

This was taken offline.