- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
Thank you
Olaf
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
thanks.
"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?
Olaf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
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
OIaf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The TRNSYS documentation should explain how to use it. I am not familiar with this library.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hmmm, I will lock
Olaf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page