forums.silverfrost.com

GMMitchell · Joined: 26 Aug 2005 Posts: 3

referring to my previous notes on this subject in which I am [still] endeavouring to link a 3rd party dll [using an export lib] to a fotran applicaiton. Success with a previous version not withstanding, I am loading the lib associated with the 3d party dll, also having to load user32.lib. With compaq visual fotran set for win32 release all is resolved, in debug mode the linker suggests that the supplied dll is corrupt. Using Salford ftn v 4.60 via plato 3 for either release or debug configuration there is no difference and the same messages appear....

Linking...
WARNING the following symbols are missing:
solveroptimize E:SPLATLink_testReleaseWin32Solver_testsmall_sdk.obj
(E:SPLATLINK_TESTSOLVER_TESTSMALL_SDK.F90)
_imp__LoadLibraryA E:SPLATSoftwarefpsdk.lib (/0 )
(.ReleaseSolverSDK.obj)
*** Imported common not satisfied: LoadLibraryA@4
_imp__GetProcAddress E:SPLATSoftwarefpsdk.lib (/0 )
(.ReleaseSolverSDK.obj)
*** Imported common not satisfied: GetProcAddress@8
_fltused E:SPLATSoftwarefpsdk.lib (/0 )
(.ReleaseSolverSDK.obj)
*** Imported common references not satisfied or Imported data missing

Why is there a difference between the compaq and Salford compilers??? Any one got any suggestions. Understandably the client is not far off pulling the plug on this project...so any solution would be very very gratefully recieved...

George Mitchell

PaulLaidler

You can use the DLL (not the LIB) when linking with SLINK.
You should also use the DLL in the /IMPORT_LIB command line option.
I thought the relevant Microsoft API was kernel32.dll but I could be wrong.

If you can reduce the problem to a few lines of Fortran (i.e. a complete program) and can send it (with the DLL) to me then I will try to find time to look at it.

mac-es · Joined: 20 May 2008 Posts: 4

Not sure wheter my problem fits here...

Have to generate an FTN95 ext.dll to be called by an external program, which only can call FTN95 generated / (s)linked .dlls (no idea why). The ext.dll fortran code has C_EXTERN declarations refering to functions written in c programming language. The following steps are done:

1. Compile c code:
cl /c prog1.c
cl /c prog2.c

2. Compile ftn95 code:
ftn95 ext.f90

3. Link with slink:
slink -dll -exportall -out:ext.dll prog1.obj prog2.obj ext.obj

ext.dll is generated and slink outputs:

PaulLaidler · Posted: Wed May 21, 2008 4:46 pm Post subject:

You should only need cprog.dll (not cprog.lib and cprog.exp) when
slinking ext.dll.

It may be simpler to use SLINK (and SCC) to create cprog.dll.

In any case you need to look up the information about STDCALL
and c_decl when calling C functions from FTN95. See FTN95.chm
for further information.

Andrew · Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany

In my experience, if you are writing your own DLL using MSVC then the easiest thing to do is to mark all of your routines as follows:

mac-es · Joined: 20 May 2008 Posts: 4

Paul, Andrew,

thanks for the quick reply!

Using scc I get the errors listed below.

Using slink instead of link yields the same missing references (if compiled with Visual C++), so I guess I have to use scc instead of cl to compile the c code. So, any idea how to resolve the scc compiler issues?

Andrew · Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany

I think we are getting confused here. The C code I supplied was for MSVC and the corresponding Microsoft linker, LINK. That would create a DLL - which you would then link with your Fortran code using SLINK.

If you can compile everything using our compilers then you do not need the export statements in my sample code and can link the *objects* directly with SLINK.

mac-es · Joined: 20 May 2008 Posts: 4

Andrew,

thanks again for the quick reply. Applying your proposal yields no "undefined references", so compiling and linking seems to be fine ("cl" and "link" for C code, "ftn95" for Fortran code and "slink" to build the two .dlls).

However, I'm wondering whether my Fortran code really calls the C functions (printf from C doesn't output anything). Maybe it's because I have two .dlls now: ext.dll and cprog.dll. Is there any possibility to merge these two files into one working .dll?

Andrew · Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany

If you are really making the call then is could be possible that due to the IO subsystem the printf is not making it out. You could call fflush to make sure.

Regardless, if you can write both your C and Fortran using our tools then yes, you should be able to create them as one DLL, compile everything to object file and then link with SLINK.

For example, some C code:

mac-es · Joined: 20 May 2008 Posts: 4

I'm using a lot of functions related to named pipes in my C code. scc cannot use the .h files needed for these functions (provided by Visual C++). Do I have to declare these functions as external (in Fortran where I'm not using them)?

So, if I use cl (Visual C++) and ftn95, it is not possible to create one .dll?

I used fflush which, unfortunately, has no effect.

Andrew · Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany

If the functions are not declared in the C headers we provide (the pipe functions are declared in winbase.h, which is included by windows.h - so are they not in the SCC headers?) and you cannot use the Microsoft one (it might be a case of just defining the correct symbols before you compile in order to make them usable by SCC) then you can extract the relevant declarations and put them in your own header. You could then compile with SCC, FTN95 and link with SLINK, and you will need to make sure you link with the Microsoft DLLs (not the libs).

You do not need to declare the functions in the Fortran if you are not calling them from there.

As for creating a DLL from mixed code, this may be possible somehow, but will be very tricky - a mixture of different libraries may be required and it could get very problematic and as such is not recommended.