Access Fortran module exported in dll from Fortran executable

[Gustavo_B_1]

I am trying to export a module (including a derived type and procedures) to a dll that can be used, in principle, by a fortran executable...

With Visual Studio, I was able to do it in a solution with two projects, one to build the dll (with the DLLEXPORT directives for the exported procedures), the other project with the code for building the executable file USEing the module derived type and procedures, by setting as a depencency the dll project (without any DLLIMPORT directives in the code, and without including the .lib within the project files). It worked. Indeed making some changes in the dll project, recompiling only the dll project and replacing the dll file copied at the executable file folder, it still works.

Nevertheless, I have understood  from other posts that it is possible to build the that executable accesing the module types and procedures, only with the .dll and the .mod files available. Is that right? Only from command line? Also with Visual Studio?

Thanks in advance for any advice!

Gustavo 

[Gustavo_B_1]

Still in Visual Studio, the .exe file is also built without assigning a project dependency with the dll project. Instead, I had to set, in the project properties, additional include/library directories to the path where the .lib and .mod files stand, and also to add, as existing component, the .lib file to the project.

But it seems I am still needing, to build and run the executable program: the .dll, the .lib and the .mod files corresponding to the module/dll project.

[IanH]

When you make a Fortran library project (static or DLL) a dependency of another Fortran project (lets call it the main program project), typically the Fortran integration arranges:

• for the directory containing the mod files created when the library project was compiled to be added to the module search path for the main program project;
• for the lib file that is generated by the library project to be automatically included in the build of the downstream project.

Hence your observations - if you remove the dependency link between the two projects, you need to manually do the above two steps.

There are two methods of dynamic linking to DLL's on Windows - generally called load time linking (happens when the executable is loaded, before the main program starts running) and runtime linking (happens during program execution when directed by the program).  What's appropriate depends on your use case. 

Load time linking requires that when the executable is linked, the linker has to have the .lib import library for the DLL.

Run time linking does not require the import library when the executable is linked - instead the programmer arranges for the program to call Windows API's such as LoadLibrary and GetProcAddress.

Complicated interfaces, such as those associated with derived types with type bound procedures, can not be used with run time linking, as the programmer doesn't have access to the internal implementation of the derived type.

[Gustavo_B_1]

Thanks for the explanations. We'll have to review it a little more and see if that approach worths for our shared modules. Regards.