Problem with linking DLL

Problem with linking DLL

Bild des Benutzers Nuno Barradas

I am trying to turn a series of sub-routines of a code into a DLL. It's the first time I do that so I'm a newbie and this is probably a trivial question. The original code compiles and runs without problems. I made a new project with the routines, it also compiled without problems. The problem arises when compiling the main program, with the LIB included.

This is the main code, where I explicitly import a routine from the DLL, and USE a module from the DLL:

program nts

use IDFCOM

!DEC$ ATTRIBUTES DLLIMPORT::calc_n

implicit none

call calc_n

write(*,*)'n:',n

end program

 

This is the DLL:

 

module IDFCOM

!DEC$ ATTRIBUTES DLLEXPORT::n

integer,allocatable::n(:)

end module IDFCOM

 

subroutine calc_n

!DEC$ ATTRIBUTES DLLEXPORT::calc_n

use IDFCOM

implicit none

allocate(n(2))

n(1)=1

n(2)=3

return

end subroutine

 

And this is the error I get when compiling:

error LNK2019: unresolved external symbol _IDFCOM_mp_N referenced in function _MAIN__

The documentation says "When a module is used in other program units, through the Use statement, any objects in the module with the DLLEXPORT property are treated in the program using the module as if they were declared with the DLLIMPORT property. So, a main program that uses a module contained in a DLL has the correct import attributes for all objects exported from the DLL."

So why can't I access the variable n, which has the DLLEXPORT attribute in the DLL, in the main routine?  The compiler does not complain about the subroutine, only about the data.

In the real code "n" is a series of allocatable derived variables. I don't know a priori how large they need to be, that's why I am transmitting them via the module.

Thanks!

7 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers Steve Lionel (Intel)

When I try a build using the sources you post, I don't get any errors. Perhaps your real source is somewhat different. Make sure you are linking against the .lib created when the DLL is built. There's nothing I can see that is wrong in what you posted.

Steve
Bild des Benutzers Nuno Barradas

thank you for the very fast answer! The actual code is a bit larger, before I post, maybe the problem is how I am including the .LIB; I followed this:

"In the integrated development environment, add the .LIB import library file to your project. In the Project menu, select Add Existing Item"

I had the "Resource Files" folder highlighted, so that is where the LIB ended up being. Is this correct?! Thanks again!

Bild des Benutzers mecej4

The documentation says "When a module is used in other program units, through the Use statement, any objects in the module with the DLLEXPORT property are treated in the program using the module as if they were declared with the DLLIMPORT property. So, a main program that uses a module contained in a DLL has the correct import attributes for all objects exported from the DLL."

Note that in the source file used to produce the DLL the subroutine is not inside the module. Therefore, the quote from the documentation does not apply. However, the subroutine in this case takes no arguments, so that the overlooked aspect of the subroutine being outside the module has no negative effect.

Please present details of how you built the DLL and how you compiled the client program.

Bild des Benutzers Nuno Barradas

Dear me; in the original code I had exactly the same routines but compiled together with the main program. So, in the project directories, the corrsponding files were there, including a module with the same name as in the newly created DLL. I now deleted all the old files and rebuilt the application, and I no longer get the error! I thought that when I remove a source file from the project the related files also disappeared, but it seems not!

I can now compile successfully, I'm getting run time errors but I hope to solve those!

Thank you again for the help.

Bild des Benutzers Steve Lionel (Intel)

mecej4, I too thought the separate subroutine was the problem, but here it was the array variable N being imported from the module that was not being found.

Nuno, I'm glad to hear that you solved the problem. Deleting a source file does not itself delete other files.

Steve
Bild des Benutzers Nuno Barradas

Thank you Steve and mecej4!

EDIT: managed to solve by playing with the compiler options for the DLL, which needed to be different somehow.

Melden Sie sich an, um einen Kommentar zu hinterlassen.