quick question:
I'm struggling with including ZeroMQ into a LVLIBP..
I'm getting Error 7, when calling the first function in the LVLIBP, that uses ZMQ (create Context).
I followed the FAQ regarding Error 7 and tried various combination of including the DLL either in the LVLIB (which get turned into the LVLIBP), or along side it, but set to always include...
I tried having the DLLs in a sub-folder named "data" or on the same level as the lvlibp..
I'm not sure if it is really the DLL missing or the ctx_create_context.vi or the lvlib from ZMQ...
I will try to create an example and upload it later...
I'm lost as to what else to try...
Any ideas?
Thanks!!
Cheers
Niels Göran
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I figured out the solution....
The problem arose from the "zmq_libpath.vi".
This VI determines where to look for the DLLs.
And that decision is based on whether the application is in RUN_TIME_ENGINE or not.
This flag is evaluated at COMPILE TIME, not run time.
So when compiling an EXE, RUN_TIME_ENGINE is set to true and the DLL path is determined in relation to the app directory and the subfolder "data" (has to be named like that).
BUT....
When you compile an LVLIBP and then run it with RTE, this flag is set to FALSE, since during compile time, it was not clear wether you would be running this LVLIBP from the dev environment or the RTE.
In both cases, the way how the DLL paths are determined, is not suitable for LVLIBPs (since they don't have a proper app directory, nor does the VI lib work.
In summary, one needs to change the "zmq_libpath.vi" in the way shown in the attachment.
This way, if not compiled for RTE, the VI checks where it is part of a packed library or not.
If not, it uses the previously implemented way via vi.lib.
But if the VI is part of a packed library, it determines the folder in which the LVLIBP resides and looks for the DLLs there.
So the following folder structure should than work:
Sounds to me like something that might be worth adding to the next release of the VIPM to avoid having to change this on every machine with the VIPM installed and after every update.
Hi Niels,
Thanks for the suggestion to change the libpath VI, I have rolled it into the next update.
I'm changing the project to use the official DLL builds, but this produces a naming problem because the 32 and 64 bit DLLs have the same filenames. For now I have put them in different subdirectories, but when compiling would it be preferable to just have the applicable DLLs in the parent directory as you suggest above?
Cheers,
Martijn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks, sounds good with the next update !!
Out of curiosity: What is the time frame for that?
(I need to keep track of projects that uses the modified lib until then, that's why I'm asking)...
Regarding the DLLs:
If I understand you correctly, you are referering to this, right?
I would prefer it that way, since LabVIEW doesn't allow you to compile for 64 when in 32 and vice versa anyway..
And I'm becoming a fan of flat folder structures
Thanks!
Cheers
Niels
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's a build to try. I think it might need some tweaking - I'm not sure it makes sense having the DLLs in the parent directory for LVLIBP but in the "data" directory for embedded. This build also provides encryption support (PLAIN or CURVE)
Regarding the DLLs, to be sure of the dependencies, you should take all the DLLs in the lib/win32 or lib/win64 directory as appropriate. Moving to the official binary builds means following their naming convention. Also, the MSVC runtimes were causing sufficiently many problems for people that I included them as well. Flat folders are great except when you don't have freedom over the filenames...
As of v3.6.2.1.1 the DLLs must be in the same folder with the .lvlibp. That should be documented. README.txt refers to http://labview-zmq.sf.net whose FAQ goes to https://labview-zmq.sourceforge.io/?faq#packaging which is outdated (just two DLLs into Support Directory which is not always the same).
Last edit: dwb 2023-11-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
quick question:
I'm struggling with including ZeroMQ into a LVLIBP..
I'm getting Error 7, when calling the first function in the LVLIBP, that uses ZMQ (create Context).
I followed the FAQ regarding Error 7 and tried various combination of including the DLL either in the LVLIB (which get turned into the LVLIBP), or along side it, but set to always include...
I tried having the DLLs in a sub-folder named "data" or on the same level as the lvlibp..
I'm not sure if it is really the DLL missing or the ctx_create_context.vi or the lvlib from ZMQ...
I will try to create an example and upload it later...
I'm lost as to what else to try...
Any ideas?
Thanks!!
Cheers
Niels Göran
Hey everyone,
I figured out the solution....
The problem arose from the "zmq_libpath.vi".
This VI determines where to look for the DLLs.
And that decision is based on whether the application is in RUN_TIME_ENGINE or not.
This flag is evaluated at COMPILE TIME, not run time.
So when compiling an EXE, RUN_TIME_ENGINE is set to true and the DLL path is determined in relation to the app directory and the subfolder "data" (has to be named like that).
BUT....
When you compile an LVLIBP and then run it with RTE, this flag is set to FALSE, since during compile time, it was not clear wether you would be running this LVLIBP from the dev environment or the RTE.
In both cases, the way how the DLL paths are determined, is not suitable for LVLIBPs (since they don't have a proper app directory, nor does the VI lib work.
In summary, one needs to change the "zmq_libpath.vi" in the way shown in the attachment.
This way, if not compiled for RTE, the VI checks where it is part of a packed library or not.
If not, it uses the previously implemented way via vi.lib.
But if the VI is part of a packed library, it determines the folder in which the LVLIBP resides and looks for the DLLs there.
So the following folder structure should than work:
Contining folder
lib.lvlibp
libzmq32.dll
lvzmq32.dll
Sounds to me like something that might be worth adding to the next release of the VIPM to avoid having to change this on every machine with the VIPM installed and after every update.
Thanks !!
Cheers
Niels Göran
Last edit: Niels Göran Blume 2021-02-26
Hi Niels,
Thanks for the suggestion to change the libpath VI, I have rolled it into the next update.
I'm changing the project to use the official DLL builds, but this produces a naming problem because the 32 and 64 bit DLLs have the same filenames. For now I have put them in different subdirectories, but when compiling would it be preferable to just have the applicable DLLs in the parent directory as you suggest above?
Cheers,
Martijn
Hi Martijn,
thanks, sounds good with the next update !!
Out of curiosity: What is the time frame for that?
(I need to keep track of projects that uses the modified lib until then, that's why I'm asking)...
Regarding the DLLs:
If I understand you correctly, you are referering to this, right?
I would prefer it that way, since LabVIEW doesn't allow you to compile for 64 when in 32 and vice versa anyway..
And I'm becoming a fan of flat folder structures
Thanks!
Cheers
Niels
Here's a build to try. I think it might need some tweaking - I'm not sure it makes sense having the DLLs in the parent directory for LVLIBP but in the "data" directory for embedded. This build also provides encryption support (PLAIN or CURVE)
Regarding the DLLs, to be sure of the dependencies, you should take all the DLLs in the lib/win32 or lib/win64 directory as appropriate. Moving to the official binary builds means following their naming convention. Also, the MSVC runtimes were causing sufficiently many problems for people that I included them as well. Flat folders are great except when you don't have freedom over the filenames...
Cheers,
Martijn
As of v3.6.2.1.1 the DLLs must be in the same folder with the .lvlibp. That should be documented. README.txt refers to http://labview-zmq.sf.net whose FAQ goes to https://labview-zmq.sourceforge.io/?faq#packaging which is outdated (just two DLLs into Support Directory which is not always the same).
Last edit: dwb 2023-11-22