I am a fortran newbie.
I think this does not work
SUBROUTINE MARKER (IMARKER,X,Y,HEIGHT) !DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE, & ALIAS:'MARKER' :: MARKER
beacue I get the error message when I call MARKER
Severity Code Description Project File Line Suppression State Error error #7519: Required explicit interface for a procedure with C or STDCALL attribute is missing from original source. [MARKER] C:\Users\c565698\Documents\Git\kplf\PUgraph\PUGRAPH.FOR 888
How it is correct?
You have declared MARKER to be called using the STDCALL convention, which is not the default convention. Any source code containing calls to MARKER should also be compiled with the STDCALL convention, if feasible; at the least, you have to add a DIR$ directive in the caller or provide an interface to MARKER in some way. Otherwise, the calling conventions are mismatched. In that case, if you enabled runtime argument checking, you will receive error message such as the one you reported. If you did not ask the compiler to do checking, mysterious run time crashes may occur.
I think i did a mess.
I use now
!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE :: _MARKER
This will be exported into _marker@16.
But I Need _MARKER@16. The executable call this routine (with upper cases)
What have I to do?
!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,DECORATE,ALIAS:"MARKER" :: MARKER
!DEC$ ATTRIBUTES DLLEXPORT,CVF :: MARKER
Note that the latter changes where character lengths are passed. Your use of _MARKER as the name in the directive is incorrect - omit the leading underscore. The compiler will add it where necessary. Note that directives can't be continued (with the exception of OpenMP directives), but you can have multiple ATTRIBUTES directives to "build up" what you need.
The error you show in the first post is the compiler complaining that you've called MARKER from a context where you haven't declared it as being STDCALL, so you need to add a directive or explicit interface saying so visible to the caller.
There are a number of compiler options as well as directives that affect the names generated for external symbols. Perhaps it would be better if you told us what you are aiming to accomplish. Are you targeting X64? For IA32, try:
!DEC$ ATTRIBUTES STDCALL,REFERENCE,DECORATE,ALIAS:'MARKER' :: MARKER
P.S.: FORUM MODERATOR: I did not see Dr. Fortran's reply when I posted this. He has already covered the issues more fully, so this post can be deleted.
I am using 32 Bit, the attributes with decoration works fine.
CALL MARKER (IMARKER,SX,SY,HEIGHT)
in the same module generates the error
Required explict interface for a procedure with C bla bla ....
What have I to do here?
I see the problem with 64 and 32 bit.
Simple solution is to add the same directive (but omit DLLEXPORT,) in the caller.
I did not think directives could be continued, but maybe they can.
I added !DEC$ ATTRIBUTES STDCALL, REFERENCE :: MARKER
Then I get the error
error LNK2019: unresolved external symbol _marker@16 referenced in function _SMARKER
because the name is _MARKER@16, I think.
How can I force upper cases?.
I tried also the other option cvf, then I can build the dll and the executable using this dll. But at running the exe crashes.
It would help us to respond better if you told us what you are trying to accomplish. Why does a "Fortran newbie" bother with non-standard calling conventions?
Normally I am using C#.
Now I have to build a Fortran DLL for existing Fortran executables. They have used I think in the build process for the exes the /iface:stdref option. (I am not shure). What I know is the dll calls are with upper cases, so _MARKER@16.
I thought that this is a simple Task.
I think that they are responsible for giving you a complete and accurate definition of the interface and calling conventions of the EXE(s) that will call your DLL, unless they are trying to subject you to a stress test.
Explain to them that they need to specify the requirements before you can begin to code the solution.
Use the directives I suggested above in post #4 (without DLLEXPORT). You left out too much.
If you're using /iface:CVF you don't need CVF on the ATTRIBUTES directive. My preference is to not use /iface at all and use directives only where needed.