Import Fortran DLL into Fortran DLL

[Carstensen]

Hi,

There are some posts on this topic, but I cannot get it to work. I have a Fortran DLL with a lot of routines I want to call from a different Fortran DLL. I'm running VS 2019 with Intel compiler 2020.4.311.

I have set the following properties:

• Properties - Fortran - General - Additional Include Directories - "PathToDllAndLib"
• Properties - Fortran - Preprocessor - Additional Include Directories - "PathToDllAndLib"
• Properties - Linker - General - Additional Library Directories - "PathToDllAndLib"
• Properties - Linker - Input- Additional Dependencies - "Test.lib"

Example of external routine:

subroutine test (path, a, b) bind (c, name = "test")
    
    !dec$ attributes dllexport, stdcall :: test
    !dec$ attributes reference          :: path, a, b

    use, intrinsic                              :: iso_c_binding
    character(kind=c_char, len=1), intent(in)   :: path
    integer(2), intent(in)                      :: a
    real(8), intent(out)                        :: b(6,3)
    
    ...
    
end subroutine

Setting up interface to use external routine:

module interface_external
    
    interface
        
        subroutine test (path, a, b) bind(c, name = "test")
            
            !dec$ attributes dllimport, stdcall :: test
            !dec$ attributes reference          :: path, a, b
        
            use, intrinsic                              :: iso_c_binding
            character(kind=c_char, len=1), intent(in)   :: path
            integer(2), intent(in)                      :: a
            real(8), intent(out)                        :: b(6,3)
            
        end subroutine
        
    end interface

end module

What am I doing wrong?

Thanks,

Carl

[Steve_Lionel]

I note that you didn't say what goes wrong, but I can guess.

You can't link to a DLL - you must instead link to the "export library" (also called "import library"), a .LIB generated when the DLL was created. An alternative is dynamic loading of the DLL, which doesn't require linking. I've attached a worked example of that.

[Carstensen]

Hi Steve, 

Well, I did link to the .lib-file. I tried to show that in my original post:

• Properties - Linker - Input- Additional Dependencies - "Test.lib"

I'm sure I can get it to work using your attached example, but it seems way easier to link it to the .lib. Any guidance on what I am doing wrong would be great. Or better, a step-by-step procedure on how to do this. I've searched, but haven't found anything.

Thanks,

Carl

[Steve_Lionel]

OK, so now I'm back to noting that you didn't say what "cannot get it to work" means. What, exactly, goes wrong? Show error messages, if any. Even better, create a complete example, zip it and attach to a reply here.

[Carstensen]

Hi again,

I have attached an example. In the example I have created a DLL containing two functions (Functions.dll), one is giving out a Double, while the other is providing a String.

These two functions are being called in the Main.dll. The Main.dll is interfaced towards the Excel-sheet. And as you can see, the calculations fail.

Note that I have tried to connect the Excel-sheet directly to the Functions.dll instead of going via the Main.dll. Then it works...

Cheers,
Carl

[Steve_Lionel]

No, I can't see because you HAVE NOT SHOWN THE ERROR!!! If you want help, you need to do your part. Shall I stare into my crystal ball again and make another guess?

It works when you call the function directly from Excel, or when you combine the function and "main" into a single DLL, because you give Excel (which you did not mention before!) the path to the DLL to be loaded. However, Windows will then want to locate the child DLL and will use its normal search list to find it - when it doesn't, Excel will complain that it can't load your DLL. Where will Windows look for that DLL? 

1. The folder containing the EXE (Excel in this case)
2. The Windows System folder
3. The Windows folder
4. The current folder (probably your user folder)
5. Folders listed on the PATH environment variable

Unless you have copied the "functions" DLL into one of those places, Excel will give you Error 53 (File not found), making you think it was the DLL you named in Excel that could not be found, when in fact it was a dependent DLL.

But even if you fix this (adding the folder with the functions DLL to PATH is one way), you'll run into another issue, that being you built a Debug configuration. This links against the debug Visual C++ DLLs which are not available to you outside of the Visual Studio environment (or an Intel Fortran command prompt.) To resolve this, either build both DLLs as a Release configuration, or (and I don't recommend this), change the properties of both projects to specify the static Fortran run-time libraries.

I could spend the next half hour or so fixing up your example (which really should be two projects in the same solution, with build dependencies set), but I have other things to do and all it would do is demonstrate that it works if you do it right.

That you have separated out the functions into a second DLL with the first dynamically loaded from Excel makes this whole task more difficult. Do you really need that?

[Carstensen · Accepted solution]

So I didn't do my part when I provided a complete example of my problem? The thing is Steve, I didn't get an error! Everything compiles as it should, and Excel seemed to find the DLL because it is not giving me any error except #VALUE! in the cell where I try to do the calculation.

And no, I don't want the two projects in the same solution. The whole point of what I'm trying to do is to separate out stuff and put it into another solution and DLL. The project I'm working on is very big, and what I have shown to you is just a simple example of what I'm trying to achieve.

I had the Functions.dll in the same folder as the Main.dll. I thought that was the correct way to do it because that was the path Excel was given. But that didn't work. However, it worked when I copied the Functions.dll into 'C:\Windows\SysWOW64'. Thanks for the tip.

And for your information, all this **bleep** is not very intuitive for a process engineer which don't have a degree in computer science.

Anyways, thanks for your efforts and have a nice day.

\Carl

[Steve_Lionel]

I asked you twice for what the error was - you never said. Yes, you provided the code, but your environment was also important. If you had said at the beginning that the first DLL was being called from Excel, I would have been able to help quicker.

Your "solution" of copying the DLL to the Windows SysWOW64 folder is absolutely the wrong thing to do. It may seem to work but is almost certain to cause you headaches down the road. Editing the system (or your user) PATH environment variable is a better choice.

I agree that none of this is obvious, but if you provide only a small part of the problem description, it's difficult to point you in the right direction.