He Steve, hi all,
once you wrote "USE has no direct relationship with DLL calls".
Does that mean, to a module wich is inside a Dll I have no contact from outside (from a fortran project where added is the dll)?
Things declared in a module that is part of a DLL have no visibility outside the DLL unless you explicitly name them in an ATTRIBUTES DLLEXPORT directive. If you do that, then if a program USEs the module, the DLLEXPORT is treated as a DLLIMPORT so you can get at the variable or procedure.
Does this answer your question?
"no visibility outside the DLL" means I can not find it if I don't know abaut it (the DLL is a thid-party product) or I can not use it?
It means that you can't call any routines in the DLL that aren't DLLEXPORTed. A DLL will typically export the routines it wants users of the DLL to call. Variables and COMMON blocks can also be exported. If the third-party didn't DLLEXPORT routines, there isn't a way for you to use the non-exported routines. You can, of course, use the DLL's exported interfaces.
I don't get what modules has to do with this question, though.
I have such a problem, because I like to use a DLL (from TRNSYS - older versions of this work with common blocks or. modules and newer versions have Interfaces to so called types -units-). And some units I don't know. (I mean I have not seen that code)
Thats why I asked.
But thank you
The TRNSYS documentation should explain how to use it. I am not familiar with this library.
Hi Steve, just want to confirm that I understand it correctly: When you say:
... If you do that, then if a program USEs the module, the DLLEXPORT is treated as a DLLIMPORT so you can get at the variable or procedure ...
does it mean that the sole purpose of DLLIMPORT attribute in the calling function is to define the interface? In other words, there is no need to have DLLIMPORT attribute in the calling function when the DLLEXPORTed routine lives in a module, which is USEd in the calling function. In this case, I suppose the compiler-generated module file of called-function should be also be present at the time of compiling the calling function. Is this correct?
Also, I am a bit confused whether these DLL flags
/libs:dll /dll /threads
are compile-time flags (necessary at compile-time, for a file that has DLLEXPORT) or they are solely link-time flags? and when /threads is really necessary to add?
Thanks in advance for your help.
DLLIMPORT and DLLEXPORT are not really related to interfaces or modules. DLLEXPORT tells the linker to make the global name of the symbol visible to users of the DLL. DLLIMPORT says that this symbol is being imported from a DLL. For procedures, DLLIMPORT is not strictly necessary, but it is for variables as the compiler has to generate different code.
So you absolutely need DLLEXPORT for any symbol in a DLL you want visible to users of the DLL. What I referred to above was that having the compiler turn a DLLEXPORT into DLLIMPORT on USE means that you don't need to keep two versions of the .mod around. (This was a change made somewhere around version 12, I think.)
If you have DLL procedures in a module, any caller of those procedures needs to USE the module, which means the .mod has to be there for the compile.
The flags you mention have distinct purposes:
/dll means "build a DLL"
/libs:dll means "link against the DLL form of the run-time library." This is now the default, it wasn't in some earlier versions
/threads means "link against libraries that support a multithread environment". Sometime around version 15 or 16, this also became the default (and the non-thread-safe libraries went away - the libraries with those names are the same as the thread-safe ones.)
Of these, only /dll is a link-time flag, the others affect compilation as they change the set of libraries named in OBJCOMMENT directives. But it doesn't hurt to add /dll when you compile.
Typically you want to link to the DLL libraries, especially if you are using a DLL built from Fortran.