ENTRY statement in a library function

[OP1]

I have a library for which I declare an interface for each subroutine, such as:

INTERFACE
FUNCTION F(A,B)
!DEC$ ATTRIBUTES STDCALL,REFERENCE,MIXED_STR_LEN_ARG,DECORATE,ALIAS:"F":: F
REAL(8),INTENT(IN) :: A,B
REAL(8) :: F
END FUNCTION F
END INTERFACE

Now, assume that F has an ENTRY statement called F_1. How can I declare/access F_1 in my main code?

Thanks,

Olivier

[Steven_L_Intel1]

Declare it as FUNCTION F_1 with the appropriate arguments. But why are you writing interface blocks for Fortran code? Put the Fortran routines in a module and USE the module.

[OP1]

Thanks Steve,

Yes, this is what I thought too. I created an interface for F_1 - but in the end the linker couldn't find it.

This library is a legacy DLL that I cannot modify - I just have to make do with it. I was just handed over the .lib and .dll files - it happens that one of the functions I need to call is declared as an ENTRY statement inside another function of the library. Maybe this ENTRY function is not exported in the wrapper DLL ? I'll have to investigate this.

Thanks again.

Olivier

[jimdempseyatthecove]

Olivier,

As a hack, write (int the DLL)a 2nd function that calls the 2nd entry point

retType function originalFunction(args)
...
F_1_Entry
...
end function originalFunction

retType function F_1(args)
F_1 = F_1_Entry(args)
end function F_1

You should be able to decorate that properly

Note, you will not be editing the original DLL code, rather you will be adding an additional function to the DLL code. This should comply with the requirement of not modifying the originalDLL code.

Jim

[Steven_L_Intel1]

You can use Dependency Walker to see what routines are exported from the DLL. It may also help to use "dumpbin -exports" on the import library (.lib) - this can be done from a Fortran command prompt session.

[OP1]

Thanks Steve - that was indeed the reason why I couldn't access this function. It's just not there in the DLL.

Now - just a comment regarding your suggestion to have all subroutines in a module. This is something you advocate often in this forum, and I agree that in most cases this is a very elegant solution. In practice, however, it is often not possible or desirable. Projects can become extremely large, for instance. Or you may not want to put mundane subroutines as well as more sensitive (intellectual property wise) subroutines in the same module file. For these reasons (and a few others) maintenance, testingand upgrades (by multiple people, when it's preferable to give them access to the specific subroutines they aregoing to work with instead of exposing the entire code)areeasier to managewhen each subroutine is easily accessible in its own file.

Olivier

[Steven_L_Intel1]

I understand that it is not always feasible to use modules, but it is what I recommend, and without additional context (such as being told that you were just handed the DLL and LIB), I thought it was appropriate to mention.

[IanH]

Can't you just have lots of modules in that case? Each procedure, in its own module, in its own file? If you want, you can also have a big super module that just "uses" all the little modules together and exposes the final higher level interface to the code as a convenience to end users/programmers.

There's an language "feature gap" (maybe fixed with F2008 sub-modules?) around visibility of private components and module variables with this approach, but that shouldn't be an issue if you're starting with stand-alone subroutine and function program units. You do have to be mindful of circular USE dependencies.

(The paste code feature of the forums appears to be broken - it's not honouring the original line endings that were present in the "pre" block)

[OP1]

Thanks Steve and IanH - your patience and pedagogic efforts are appreciated very much, as always.

IanH, yes, your approach is another option, but as you also mentionned, it's easy to get caught in a tangle of modules cross referencing each others... I am talking about really large codes.
There is also the issue of knowing what file contains what in the end. With only one program unit per file, it is easy to organize/find what you're looking for.

In the end, there is probably not a best solution in absolute terms.Steve's suggestion is the most efficient when you accept (or can) include all the subroutines in a few modules; it's the best for easily containing (no pun intended) your code in a small set of files.

Olivier