Silverfrost Forums

Welcome to our forums

Exporting functions in modules

9 Dec 2015 11:13 #17069

For reasons too convoluted to go into here, i'd like to be able to export a 'clean' version of a routine in a module:

as a simple example, take NEW2.FOR:

!ftn95$free
  MODULE Z
  contains 
  subroutine y
  yy=8
  end subroutine
  end module

if this file is linked using:

dll
exportall
lo new2.obj
map
file 

then the map file has the following 'objects': 10001000 Z!Y new2.obj (NEW2.FOR) 1000101e Z!Z new2.obj (NEW2.FOR)

but i'd like the subroutine to be callable using a name that doesn't contain the '!'. i've tried changing the exportall to:

export Z!Y=new_y

but it doesn't seem to work?

K

9 Dec 2015 8:29 #17071

I don't understand why you want to export module procedures with altered names, but here is how.

Here is the source code for the module, which is to be used to build the DLL. This code is placed in file kmod.f90.

  MODULE Z 
  contains 
  subroutine y(a,b) 
  b=2*a
  return
  end subroutine 
  end module 

We build the DLL using

ftn95 kmod.f90
slink /export:Z=Z!Y /DLL /out:kmod.dll kmod.obj

Here is a test program that calls the DLL just built. The source code is put into kpgm.f90.

program kpgm
real a,b
!
a=5
call z(a,b)
print *,b
end

We build the EXE from this.

ftn95 kpgm.f90
slink kpgm.obj kmod.dll
10 Dec 2015 8:41 #17072

thanks, i'll give it a try.

K

10 Dec 2015 12:57 #17073

hmmm,

seems as though it works via the command line but not in a script?

aha! The export command is case sensitive?

export new=Z!Y doesn't work but export NEW=Z!Y does

tks

While i'm playing with this, does anyone have an example of how to use the 'export data' link command?

http://www.silverfrost.com/ftn95-help/slink/the_export_command.aspx

K

10 Dec 2015 1:22 #17074

Most Fortran compilers and linkers that are used currently have to be able to work with parts of code written in C, assembler, etc. Unlike C and assembler, Fortran treats upper and lower case symbols (variable names, routine names, common block names, etc.) as one and the same. Therefore, a convention is needed as to what case to use in OBJ files. On Windows, most Fortran compilers convert symbols to upper case, but an underscore may be added as a prefix or a suffix. On Linux, Fortran symbols are converted to lower case.

At link time, the OBJ files generated by the Fortran compiler have to be linked with OBJ and LIB/DLL files generated by other tools, as well as with the Fortran RTL (Run Time Library). Thus, the case of symbols is significant, and whether you link using a batch file, single commands, a Make utility or a linker script, this requirement has to be satisfied.

10 Dec 2015 9:56 #17076

Quoted from John-Silver

... Does that mean that, following the example given above of MODule usage and calling, one could utilise a routine written in C, or indeed for that matter a routine written in F77, with the main bulk written in FTN95, and if so what interface (of variables, etc...) issues are there likely to be ?

Yes. Furthermore, whether you are aware of it or not, you are already doing this every time that you use FTN95 to build one of your programs. The Salford runtime, SALFLIBC.DLL, was probably written in C or a mix of C and Fortran. To use it, however, you do not need to know the details as long as you adhere to the calling convention.

If you are prepared to knock together bits of glue code in C, you can even use libraries from other vendors. For example, you can use the routine vsErf from the Intel MKL library ( https://software.intel.com/en-us/node/521811 ) as follows:

extern void vsErf(int n, float *a, float *y);
void ERF(int *n,float *a, float *y){
vsErf(*n, a, y);
}

Once you compile this C code into a DLL, you can call ERF() in your FTN95 source code and link to the DLL.

program xerf
implicit none
integer n
real a(4),x(4)
n=4
a = (/1.0, 1.5, 2.0, 2.5/)
call erf(n,a,x)
write(*,'(4F10.5)')x
end
Please login to reply.