User library not added to executable

[AeroSoul]

Hello

So i am using Carya PDF toolkit and i've been having trouble with the library after executable is built.

The toolkit VIs i'm using are detected under dependencies, but the dll does not seem to be added to the executable (or the data folder).

If i manually add the PDFlvzlib.dll to the project and select as "always include" in the build menu, it still does not get added to the executable. If i manually add the dll to the data folder of the executable, it is not detected. If i manually add the dll to the root folder, where the executable is, then it is detected and there are no further problems. I don't like this though, i would like the dll in the data folder, with the other dlls.

I have no problems with the other dlls, they get added to the data folder and execute as expected, only this one does not get automatically included.

Am i doing something wrong, is the dll corrupted or is LabVIEW just being iffy?

Further info: using LabVIEW 2019 32-bit and the toolkit has been installed in it's user.lib folder. Toolkit VIs can be normally accessed through the functions palette, under user libraries.

[Andrey_Dmitriev]

Checked this (PDF Pro Library V2_1b10) using LabVIEW 2023 32-bit and everything "out of the box", it works without any additional actions, at least for PDF Simple.vi example bundled into the toolkit:

The DLL cannot be added "to the executable", this file copied to \data folder as expected. Try to create simple project "from the scratch" or contact Carya support.

[AeroSoul]

Thing is, i've previously had a project where i used this toolkit and it worked fine, as expected. It's only this project that doesn't seem to work right. Could the project be corrupted? Seems unlikely, as everything else works fine, even other libraries.

[Andrey_Dmitriev]

This DLL is also present in Preview window (at least for me):

May be occasionally you placed this DLL to the Windows's system folder like C:\Windows\SysWOW64, and when loaded from that folder, then it could happened that this library is not deployed like other system libraries (just suggestion)?

[AeroSoul]

Could you show me how your source files look? The preview for me does not show the dll file anywhere.

[Andrey_Dmitriev]

---

@AeroSoul wrote:

Could you show me how your source files look? The preview for me does not show the dll file anywhere.

---

The only VI added here, nothing more:

I just open the "PDF Simple.vi" from examples, then Tools->Build Application (EXE) from VI (this automatically created for me project and Build Spec), that is.

[rolfk]

Did you check that that DLL did not get “accidentally” copied into some system folder? As it is a renamed copy of the original OpenG ZIP library, I know for sure that it is not some very nasty one.

Can you dive into the toolkit until you find one of the VIs calling this DLL? Then open its diagram and there the Call Library dialog. What path to the library does it show?

The DLL also should be present in your project dependencies and there it should be possible to see its path too.

[AeroSoul]

I'll check, but the VIs are password protected.

[Andrey_Dmitriev · Accepted solution]

---

@rolfk wrote:

The DLL also should be present in your project dependencies and there it should be possible to see its path too.

---

You will be surprised, Rolf, but this DLL is not shown in the dependencies:

The only way how can I "reproduce" this issue, is to disable here:

Then DLL is not present in \data Folder, but this is expected behavior.

In PDF ZLIB Deflate__ogtk.vi everything looks fine, I will not show password-protected diagram, but it looks like the full absolute path is not stored here:

So the call looks like that:

And the DLL is located in the same folder where SubVI.

[rolfk]

Not that there is anything secret in that VI. If you download the OpenG ZIP library you will get the according VI containing that Call Library Node without password. 😁 It's name is ZLIB Inflate.vi and ZLIB Deflate.vi.

I think I see why it doesn't show up in dependencies. I used the wildcard name in the Call Library Node to make it work for Linux *.so and Mac *.framework too. Seems the dependency view doesn't resolve these things, only the VI does at runtime.

However while the path is indeed entered without full path and accordingly stored, the Call Library Node dialog usually tends to resolve the path anyways when its opened again to show the full currently used path.

By the way I'm in the final process of releasing an OpenG ZIP package version 5.0. It should support Windows and Linux out of the box and have many low level improvements including support for long path names and Unicode encoding (although the last one is still experimental in the Linux version. There are simply so many possible variants that I need to check out on how the system can be setup that testing of it seems almost impossible).

Support for Linux RT should be coming a bit later, it's proven to be kind of complicated.