Problem with DLLs in Fortran

[wrhagen]

OK, your suggestions make sense to me. Let's close this discussion, and I'll try to get support from Intel.

[rolfk]

If you find the solution, I would love to hear about that  I’m very unlikely to learn Fortran in my old days, but always good to learn new things that could relate to other uses with the Call Library Node.

[wrhagen]

For the time being I decided to accept your answer (in short: not a LabVIEW problem, but an Intel Fortran problem) as a solution of sorts. I wanted to stop the flow of suggestions into my mail box, because I have seen them before multiple times  over the last 10 or so years in questions raised by others related to mixed-language programming in LabVIEW.

Anyway, I will continue searching for a solution to my (now Intel Fortran) problem whenever I find the time. In the meanwhile I circumvent the problem by leaving out certain intrinsic operations from my Fortran code. This is acceptable since most of the number crunching is done with linear operations such as matrix diagonalizations, which are apparently accepted in the procedure of creating a stand-alone application.

By the way, we could continue this exchange of ideas locally as we happen to work in the same institution, be it at the two far ends of the Delft campus (I am an emeritus professor of enzymology in the Biotechnology Department).

[Andrey_Dmitriev]

---

@rolfk wrote:

If you find the solution, I would love to hear about that  I’m very unlikely to learn Fortran in my old days, but always good to learn new things that could relate to other uses with the Call Library Node.

---

It's not very complicated; I just installed Intel OneAPI Fortran during my lunch break. Funny experiment, the last time I programmed in Fortran when I was a student, around 30 years ago. As far as I remember, it was Runge-Kutta...

Anyway, the tools (I always use the latest available versions):

Intel OneAPI Base Toolkit 2025.0.1 + Intel OneAPI Fortran 2025.0.4
Visual Studio Professional 2022 17.13.2
LabVIEW 2025 Q1 (64-bit) 25.1.1f1

Project created from scratch:

Source code (sin and cos only):

!  FortranDll.f90 
!
!  FUNCTIONS/SUBROUTINES exported from FortranDll.dll:
!  sin_sub & cos_sub - subroutines 
!

subroutine cos_sub(x, y)
  ! Expose subroutine cos_sub to users of this DLL
  !
!DEC$ ATTRIBUTES DLLEXPORT::cos_sub
    use iso_c_binding
    real(c_double), intent(in) :: x
    real(c_double), intent(out) :: y
    y = COS(x)
end subroutine cos_sub

subroutine sin_sub(x, y)
!DEC$ ATTRIBUTES DLLEXPORT::sin_sub
    use iso_c_binding
    real(c_double), intent(in) :: x
    real(c_double), intent(out) :: y
    y = SIN(x)
end subroutine sin_sub

The library FortranDll.dll was generated. Dependencies:

So, it depends on libmmd.dll, which is the math library for the Intel Compiler (the "d" is not for debug; the debug version is named libmmdd.dll). This library is located by default in the "C:\Program Files (x86)\Intel\oneAPI\compiler\2025.0\bin\" folder, just copy near own DLL.

I see no other third-party dependencies.

Also not dynamically loaded, it seems to be these two are sufficient:

For some x (but not for every x) the sin and cos are exactly the same with LabVIEW:

Quick and dirty benchmark just for fun:

Result:

LabVIEW is faster this time (but DLL call itself is also additional overhead)

Both parameters are passed by reference. (for sure, `x` can be passed by value, but I'm too lazy for further experiments, sorry, my lunch break is close to finish now)

Test project is attached.

[rolfk]

Great to see your work. For me there are several reasons NOT to try this:

- I have exactly zero experience with Fortran, and 0 interest to learn it. It would likely take me a few days to get something that compiles without errors and then I'm still not sure it is actually correct. 😁

- My computer is already infested with way over 50GB of NI software and additional Beckhoff, and Altium and Visual Studio and what else. I have no idea what installation of Intel Fortran and its according OneAPI support will do with that, but my expectation is not that it will improve stability. It could potentially hose the LabVIEW Advanced Analysis library which uses the Intel Math Kernel Library, now an integrated part of the OneAPI initiative. And not sure about other things like any of the Xilinx tools.

I already have to force restart my computer every time after cold starting it, as it otherwise hangs up almost completely after just a few minutes of runtime. Irritating but not enough to spend serious effort into investigating the cause.

As to performance improvement, a quick thing to do to reduce the overhead of the DLL call would be to disable the Call Library Node Error Checking. I'm pretty sure that will make a significant difference.

[Andrey_Dmitriev]

---

@rolfk wrote:

Great to see your work. For me there are several reasons NOT to try this:

- I have exactly zero experience with Fortran, and 0 interest to learn it. It would likely take me a few days to get something that compiles without errors and then I'm still not sure it is actually correct. 😁

- My computer is already infested with way over 50GB of NI software and additional Beckhoff, and Altium and Visual Studio and..

---

For me, it's almost the same. I was just curious and have some nostalgia about Fortran. The code above was written mostly by AI, and for such experiments, I have an old standalone PC, not intended for production. Visual Fortran Compiler 2020 might have completely different dependencies, but for me this old version is out of scope.

[wrhagen]

Apologies for my slow response; I was occupied for a few days. Andrey, thanks for your suggestions, which unfortunately, did not solve my problem. Perhaps I should reformulate: I can write any DLL in Fortran and successfully call it from a LabVIEW program. I can turn it into an Application, which will work nicely. The problem arises when I transfer the Application form the host computer to a target computer on which LabVIEW runtime engine is installed but no LabVIEW development system. Then LabVIEW will not recognize Fortran DLLs that contain certain functions (e.g., SIN). This also happened when I exactly copied your example. The libmmd is in the right place on the target computer. I also tried to put it (actually several versions) closer to your application, alas to no avail. So the problem is still there.

A minor point: your timing measurement of LabVIEW versus Fortran.DLL gave a factor of 22. However, it is perhaps not so realistic to call a small DLL one million times. When you call the DLL a single time, and calculate SIN one million times within the DLL, then the factor goes down to 2. Even that may not be very practical. I would call a Fortran DLL in order to do complex, many-line calculations for spectroscopy, and these might every once in a while have to do one, or a few operations like SIN.

[Andrey_Dmitriev]

---

@wrhagen wrote:

Apologies for my slow response; I was occupied for a few days. Andrey, thanks for your suggestions, which unfortunately, did not solve my problem. Perhaps I should reformulate: I can write any DLL in Fortran and successfully call it from a LabVIEW program. I can turn it into an Application, which will work nicely. The problem arises when I transfer the Application form the host computer to a target computer on which LabVIEW runtime engine is installed but no LabVIEW development system. Then LabVIEW will not recognize Fortran DLLs that contain certain functions (e.g., SIN). This also happened when I exactly copied your example.

---

You are doing something wrong. I just installed Windows 11 'out of the box' under a VM, then installed the LabVIEW Run-Time Engine (nothing more was installed except VMware Tools):

then turned the tester into an application, copied to that fresh VM (don't forget libmmd.dll !) and it works without problems: