Linking 3rd Party dlls with F95 applications

I have developed an application in F95 using the Salford compiler [with Winteracter v6.1 for the front end as well] which also has a 3rd party dll. Within this code is an interface routine with the usual STDCALL statements to allow the fortran to interface to the c++ dll. The export library is linked in and all is well. I have been sent a new version of the code and despite checking for changes in routine names and altering where appropriate all the symbols required from the dll are reported as missing at link time. In addition if I use slink to re-export the original dll to a new .lib file and use that [thinking that it would test the exporting process] with the original version of the code the link fails as well. There is clearly something about the way the export is done which is different betweent the old .lib file and the new one and the new one I created from the old dll. What on earth is going on? I am baffled...no doubt someone with more experience than I dealing with dlls will know...and I'd be very grateful for some advice...anyone?? Is there a setting required when carrying out the export to produce the .lib file?

George Mitchell

I assume that you are using /IMPORT_LIB for the 3rd parth STDCALL DLL. After that I would use SLINK with MAP (and possibly DECORATE) to get details of the mismatch. I don't see how it will make any difference if you recreate the 3rd party DLL using SLINK unless you want to change the name of a routine in which case it would be simpler to change your code.

LoadLibrary, and GetProcAddress are Windows API functions located in Kernel32.dll. However, I would have expected SLINK to reference Kernel32.dll without the user having to load it. LoadLibraryA is the ASCII character alternative to LoadLibraryW (the wide character form). @4 and @8 are standard STDCALL decorations all of which should be handled by SLINK automatically.

If SLINK managed to create the executable then you will be able to use it until these functions are called. You could try loading kernel32.dll (in SLINK) after loading the third party dll but this should not make any difference. Within SLINK (in script mode) you can use LURE to list unresolved references.