Unable to load DLL in Call Function Library Node

[bearb]

I'm currently trying to run a 64 bit dll made in visual studio on NI LabView 2016 (64 bit).

I've made three functions that all use arrays as inputs (double*) to debug some problems I've had on another project.  The first function checks if basic array modification works, and it does. The next two functions require the armadillo linear algebra library's matrix class.  The second function sees if basic armadillo functions work by creating a matrix, initializing it to zero, and setting the input array to those values in the matrix. This too works.

The problem is with my third function, "testSolve." Anything outside of basic armadillo functionality (creating matrixes, adding matrixes, etc.) requires additional libraries called "LAPACK" and "BLAS." testSolve tests if one of these kinds of functions works -- solve(A, B). This is supposed to be the c++ equivalent of the matlab backslash operator.

If I block off line 51 "X = solve(A, B);", where A, B, and X are armadillo matrixes, the dll loads and is fine. However, when I include that line, I get an error "Call Library Function Node 'Test_dll:?testSolve@@YAHPEAN00@Z': Library not found or failed to load.

My suspicion is that Labview doesn't know how to reconcile that the Solve function requires the LAPACK library. To make solve work in a executable file, I had to:

1. Direct the Additional Include Directories to the armadillo include folder that includes the header and instruction for the armadillo functions

2. Direct the Additional Library Directories to a folder with p recompiled LAPACK and BLAS libaries and dll's

3. Include the names of the LAPACK and BLAS libary files in the Additional Dependencies

4. Copy and past the LAPACK and BLAS dll files to the same location as the executable

Doing this worked like a charm. did all these steps for the dll file, except I copied and pasted the dll's to the same location as the .vi file I have from labview. Since the first two functions work and the second function includes basic matrix functionality, but the third one that requires the LAPACK library didn't, it seems linking LAPACK is the weak link. I just don't know how to solve it.

I've attached my DLL cpp file, executable cpp file, the precompiled lapack and BLAS dll's , and my Labview Project. I did not include the libraries since they could not be uploaded.

Any help would be appreciated!

[majoris]

I can't compile your code since you don't provide all the source to compile it nor do you provide the DLL you generate for me to pop into Labview. You're right that where your DLLs are matter. It's not really a Labview thing. It's more of a Windows thing. It's not obvious how the DLLs are loaded since most of the source isn't included. But it isn't by Labview; it's probably by some of that armadillo code or something.

[nathand]

Try putting the supporting DLLs either in the same folder as your LabVIEW.exe or in a Windows system directory, or put them somewhere else and then add them to the Windows path. See http://digital.ni.com/public.nsf/allkb/BF3AB44069EB3E9D8625755400758E9A

[bearb]

I couldn't upload everything, but here's a link to a Box that includes all the files I use. Note in the DLL, both Solve() and Inv() rely on lapack and will cause the program to crash.

Box Link: https://umich.box.com/s/l15f0baw62aejb9rhsqwhedz39z8camb

[bearb]

I have a labview.vi file.  Is there an .exe somewhere else?

[nathand]

Yes, there's LabVIEW.exe, wherever you installed LabVIEW. For example a 32-bit install of LabVIEW 2015 on Windows will be in C:\Program Files (x86)\National Instruments\LabVIEW 2015\LabVIEW.exe. However, adding to your PATH environment variable is a better choice than putting the DLLs in the LabVIEW directory.

[rolfk]

---

@bearb wrote:

I couldn't upload everything, but here's a link to a Box that includes all the files I use. Note in the DLL, both Solve() and Inv() rely on lapack and will cause the program to crash.

Box Link: https://umich.box.com/s/l15f0baw62aejb9rhsqwhedz39z8camb

---

If you say crash, you mean a crash or simply an error message that the DLL could not be loaded?

Follow the advice from Nathan. While you can tell the Call Library Node from where to load the initial DLL file, LabVIEW has not really any control over how Windows will locate and load secondary dependencies that this DLL might have. Windows has specific locations it searches when looking for such DLLs by name and if it doesn't find even a single of them in one of these locations, it will simply fail the load altogether and return an error to LabVIEW (which causes the error message you see). Technically the load failed, but there is no trivial way for LabVIEW to detect why it did. This could be because the DLL isn't present, which LabVIEW tries to detect beforehand, or because  Windows considers the DLL itself damaged, or in most cases because some secondary dependency of that DLL could not be found by Windows.

Locations Windows will check for such DLLs in this order:

1) already loaded into the current process

2) in the application directory (where labview.exe resides for when running in the IDE)

3) the current directory (this is initially the same as 2) when a process is started, but gets automatically updated by some Windows APIs such as the native file dialog when successfully selecting a file or directory in there)

4) the windows system directory (system32 or syswow64)

5) the windows directory

6) any directory listed in the PATH environment variable

6) is generally a bad idea as this environment variable is limited in length and Windows starts to behave very badly when the contents exceeds that limit (around 1000 characters)

4) and 5) should be avoided for application components where multiple versions could be present in a system due to different applications using different versions of those libraries (the QT libraries being a very prominent example of this as you can crash badly if some component tries to load a different version of those libraries than what it was compiled against. LAPACK and BLAS are other libraries that exist in enough different and incompatible binary flavors that you should probably try to avoid putting them in one of these directories.)

3) is to unreliable as it can change arbitrarily if you ever call the File dialog function in your app

2) is the most secure, but requires some specific packaging when building an app and does clutter the LabVIEW directory when running in de development environment, one possibility to avoid this cluttering when running in the development system, seems to be to put those libraries into the same directory as your project file. LabVIEW seems to somehow add this directory to the application context that Windows uses when trying to load DLLs. However I never found out if this a reliable mechanisme or just worked for some obscure reasons. 

1) Is a possible workaround if your application consists of a two stage loading mechanisme. With that I mean that you have a loader with a splash screen that could first call some VIs that reference these DLLs in some way even if they don't really call any function, like a Call Library Node in a case structure that normally does not get executed at all. Then you invoke dynamically the actual main VI which loads the entire hierarchy into memory and once that main VI signals to your loader that it finished loading and is ready to run, the loader terminates itself.

[nlhnt]

I am dealing with a similar issue right now. Adding the dll files to the main project directory fixed the issue.
Loading some random methods belonging to dependencies into the LV memory works as well - but this is a hassle and not really a good practice.
Have there been any updates in this field?

Edit: One thing you could try would be using Fody/Custora software package.