search

fieldrndservices / libssh2-labview

A LabVIEW library for SSH client support via libssh2
Apache License 2.0
22 stars 2 forks source link

Missing Files (VIPM Installation) #56

Open ktfergusson opened 2 years ago

ktfergusson commented 2 years ago

Hi,

When looking at the dependencies of the installed vipm package it is noticeable that the required library dependencies are missing from the toolkit library but are still present on disk:

image

Given they are not present as part of this library it means the dependencies are not included when creating source distributions from the code that calls this library and I am having to install the libraries separately.

volks73 commented 2 years ago

@ktfergusson I created a new project in LabVIEW 2021 32-bit on Windows 10 and added the "Initialize.vi" and "Shutdown.vi" from this toolkit to a new VI. This added the Field_RnD_Services_LIBSSH2_Toolkit.lvlib to the Dependencies tree node in the Project Explorer, under the vi.lib virtual folder. I expanded the Support virtual folder and I have the same missing DLLs, dylib, and SOs. I am able to re-produce the problem.

Now for the solution...

If I do a "Find->Missing Items" on the DLLs, a dialog appears that lists the a table with each missing item and a "Path" column. The Path column indicates it is expecting the missing files at C:\libssh2lv-x64.dll, etc. It looks like somewhere in the building and packaging of the toolkit into a VIP, the paths are changed.

A temporary workaround is to remove the missing items from the Project Explorer and then add the DLLs, dylib, and SO back into the Support folder from the appropriate on-disk location, C:\Program Files (x86)\National Instruments\LabVIEW 2021\vi.lib\Field R&D Services\LIBSSH2 for LabVIEW\Toolkit\Support\.

I will investigate the packaging process to see where the path is lost. I cannot guarantee a time or date on resolution, but I would be happy to review and merge any Pull Request (PR) that may fix the issue.

ktfergusson commented 2 years ago

@volks73 Thanks for your quick response on this.

I considered the workaround as you suggested but was a little hesitant to start modifying installed packages in case further releases didn't fix the issue and the customer is back to square one without realising.

Instead we distribute the dll's separately as part of the installer to a defined location and provide the path in the source to the "initialize.vi". Which looking at how the path is built we may have had to do anyway.

It's certainly not a road block at this stage but just wanted to make you aware going forwards!