09-15-2015 10:25 AM
I have created a C++ dll in MSVC. Then I created a LabVIEW VI to test the proper operation of my code. For the first time, when I used the dll without any 3rd party library it works fine as it supposed to. Then I added a 3rd party library for matrix operation called 'armadillo'. Now basically my dll calls armadillo dll to do some simple vector and matrix operation like transposing a matrix. Unfortunately after adding the matrix operation nothing is working. Even the previous functions which were working before without adding armadillo.
I have placed 3rd party dll in the same folder as my custom dll. I set the error sending priority to highest to see the possible error during execution. But it is neither showing any errors nor working. All my function return value is 0.
Any help really appreciated.
-Sahadat
09-16-2015 12:51 PM
Hi sahadat,
What steps are you taking to embed the third party dll into your custom dll?
09-16-2015 02:08 PM
Hello,
Thanks for your reply. I am following this steps:
http://www.ni.com/white-paper/3056/en/
For some reason I was not able to attach my files. You can download my project here:
https://www.dropbox.com/sh/vvuqm06llfgqkzo/AADKkgDuW6ElQimyRrIOjqu9a?dl=0
_
Sahadat
09-17-2015 09:41 AM
Hi sahadat,
Could you try embedding the third party dll in your dll using the following tutorial: https://msdn.microsoft.com/en-us/library/168k2ah5(v=vs.71).aspx
09-17-2015 10:18 AM
Hi,
My EasyDLL solution project is exactly doing that. It is basically combining the armadillo library. The DLL itself has a main function and that is the starting point of the execution.
BTW did you take a look at my project files?
-Sahadat
09-18-2015 07:57 AM - edited 09-18-2015 07:58 AM
Embedding DLLs inside other DLLs is not exactly a nice solution to try to avoid those troubles. You should rather learn how Windows tries to locate DLLs. When a DLL depends on another DLL it only requests the DLL name without any path. In that case Windows will search in specific locations that are slightly Windows version dependent. The directory in which the DLL resides that requires this dependency however is NOT part of the directories that Windows searches.
Here is is pretty exhaustive list of directories that Windows will search for DLL requests without qualified path. Unless the third party DLLs are part of a well known package with its own installer you should generally put them in the same directory as what your process executable is located in. For the LabVIEW IDE that would be the directory where LabVIEW.exe is located but newer versions of LabVIEW explicitedly add the path were your project file is located to the Windows search list.
For your build executable you should always make sure those DLLs are in the same directory as your <myapp>.exe. The LabVIEW application builder puts directly referenced DLLs by default into a "data" subdirectory which is fine as the Call Library Node is correctly updated in the build executable to point to that location, but for secondary dependencies LabVIEW is not involved in any way about finding them so you have to conform to Windows rules.
Alternatively you could write your DLL in such a way that it explicitedly loads the secondary DLLs from whatever path you know they should be in. But that also requires you to either import all the functions from those DLLs dynamically too or at least use an import library for them that uses delay load for the symbols. Otherwise your code to locate the DLLs yourself hasn't any chance to get called before Windows tries to resolv those dependencies during loading of your primary DLL.
09-18-2015 01:32 PM
I am not sure whether you understood my problem or not!!! The DLL that I created works in my C++ Test app. Here I am not having issues in windows or C++ environment. That is working perfectly as it supposed to. But same DLL does not work when I created a LabVIEW block. I kept the directory same for both the DLLs as suggested.
Again my problem is not integrating and making it work in C++ environment. I am having issues using my DLL which calls another DLL in LabVIEW.
-Sahadat
09-18-2015 02:06 PM - edited 09-18-2015 02:08 PM
Does your C++ executable you use to test thiis happen to reside in the same directory as your main DLL and the other DLLs? That would be the difference! Windows does NOT care where a DLL is located that depends on another DLL through an import entry. It only cares where the executable is located in whose process space the primary DLL got loaded.
Your process executable and all the DLLs it depends on directly and indirectlly are located in the SAME directory then. Works fine of course.
Now you call the DLL from within LabVIEW: It's very unlikely that you have copied all your DLLs into "C:\Program Files\National Instruments\LabVIEW 201x". But that is where the process executable of your current process is located when you run inside the LabVIEW IDE. And that is where Windows WILL search for DLLs that are requested as secondary dependencies by your DLL.
Please note that I'm not advocating to copy all your DLLs into "C:\Program Files\National Instruments\LabVIEW 201x". That is a horrendible solution for long term maintenance of your LabVIEW program. It SHOULD however also work if you put all those DLLs into the same directory as your LabVIEW project.