Using module (.mod) files

[krishnabc]

I wanted to use the .mod files to other projects which are created ina project . I followed the steps described in this link(examples too, actually). However, Igot linking errors (error LNK2019: unresolved external symbol...). I also tried to put the .mod files in another directory using /module:path option andlocating itwith /I compileroption in another project, but no avail. Surprisingly, I was successful to compile and run the second project atonce using the above approach.I think it was successful when both .mod and .obj filesof the moduleswere there. Later, I didn't find .obj files, andthat could be reason ofthe error LNK2019, I think.

Would appreciate your suggestions.

[Steven_L_Intel1]

I don't see the sources. Can you just zip up the whole solution and attach it? Do a Build > Clean Solution first.

[craig_h]

Oh sorry my message wasn't clear. I meant that I found the reason the static lib is in there twice and where they come from (source). Oneis in there becasue of adding the static library file name to the Linker input properties and the other from changing the Project Dependencies.

I can't attach the source code because it is proprietary. I understand if this isn't enough info to diagnose the problem but let me know if there's anything else I might be able to provide that would help.

Even if there isn't enough info could you try to answer my general questions in post 19?
Thanks
Craig

[Steven_L_Intel1]

All of the !DEC$ directives are documented in the Language Reference part of the on-disk documentation. Read the chapter on "Directive Enhanced Compilation". (That's what we tell the Intel VPs that DEC stands for...) You can also look at ATTRIBUTES under the "A-Z Reference" section. Or perhaps even better, place the cursor on an ATTRIBUTES directive and press F1.

[Steven_L_Intel1]

Let me restate a few things to see if it helps.

There are two types of "library" projects, static libraries which ONLY output a .LIB, and dynamic (DLL) libraries which output a .DLL, a .EXP (which you can ignore) and a .LIB. This .LIB is an "export library" which contains no code but provides the linker something to connect to.

When building a DLL, you must "export" one or more names, or else nobody can call the routines in the DLL. This is done, in Fortran, with an ATTRIBUTES DLLEXPORT directive in the scope where the thing to be exported is declared (usually inside routines, though variables and COMMON blocks can also be exported.

Each name that is exported gets a corresponding entry in the export library with a __imp_ prefix supplied by the linker.

When you want to call a routine in a DLL, the normal way is to have a corresponding ATTRIBUTES DLLIMPORT directive which says "this name comes from a DLL". This makes the linker look for the __imp_ name in an export library. As it happens, you don't HAVE to do this for routines. You can omit the DLLIMPORT and the linker will find the entry in the export library, but each time you call there will be a few extra instructions executed. (For variables, you must have the directive.)

We do a useful thing with Fortran modules - if you have a module that contains things with DLLEXPORT directives, and then USE the module, we convert those into DLLIMPORTs. So the caller doesn't need to explicitly add DLLIMPORT directives if they USE the module. If you also use the module in the process of building the DLL, the linker will gripe about a locally defined symbol that was imported, but that is harmless and can be ignored.

Does this help at all?

[craig_h]

Yes this definitely helped explain things. So is the problemthat I have dllexport statements but am trying to create a static library and since I don't have dllimport statements it has trouble with the __imp_ prefix symbols?

It also sounds like if I was using modules with a USE statement it might take care of the issue. Is that what you are getting at with the last paragraph?

Is there a way to get the code to work as a static library without removing the dllexport statements or adding module declarations? I would prefer not to edit this 3rd party library.

Can / Should I use dllimport statements in myexecutableeven though I'm calling a static library?

Thanks again for all the help. I feel if I was a more experienced programmer this would probably be resolved by now.
Craig

[Steven_L_Intel1]

If you are linking to a static library, then you should not use DLLIMPORT directives, nor should the modules you are USEing have DLLEXPORT directives. A common way of dealing with this is to conditionalize the DLLEXPORT directives based on a preprocessor symbol such as DLL that you add only to configurations that build a DLL. Note that the compiler-provided _DLL symbol isn't useful for this as it refers to which run-time libraries are being used.

[craig_h]

Steve
Thanks again for all the help and sorry to drag this out. I think I'm starting to understand the problem now regarding the dllexport directives. I have a few more questions then hopefully this will be wrapped up.

There are quite a few dllexport statements in the .lib I'm trying to make and as I mentioned this code wasn't written by me. So is there a way to make the preprocessor not look at these without adding the DLL symbol and conditional statements to each instance of dllexport?

I've gotten the .exe to compile by adding the .lib file to the project (as in right click on .exe project then select add file and select the .lib file). This as opposed to adding the library in the properties linker options.
Is there anything wrong with doing it this way?
Have you ever heard of doing this?
Do you know what is being done differently in terms of how the compiler sees it? It seems like it might be, in a way, handled more similar to just adding the source files to the .exe project rather than creating a separate .lib or .dll?

Again thanks for all the help. I think I've learned quite a bit.
Craig

[Steven_L_Intel1]

Adding the .lib to the project is fine. There's no difference in how it is handled by the linker (the compiler doesn't look at .lib files). Even though you have it as a "source file" it is properly dealt with. If the .lib comes from a subproject, my usual preference is to let it be dealt with as a project dependency but that may not meet everyone's needs.

There is not an option to disable recognition of DLLEXPORT/DLLIMPORT directives.