CLN paths not changed by VIPM on Linux

[Martijn]

Hi all,

I'm packaging a library that makes calls via a Call Library Node (CLN) to a shared library. On Windows this is to a DLL and works fine - the installed packages have their library paths changed to match the location of the installed DLL. The development path looks like is C:\dev\projs\labview\...\library.* which gets changed to C:\Program Files\National Instruments\...\library.* as expected. However, when installed with VIPM under linux, it turns into /C/dev/projs/labview/.../library.dll - the path separator has changed but the path is meaningless.

 

I had expected the same behaviour under Linux - that the path would transform to the appropriate vi.lib location. Should that be happening, or do I need to implement VI scripting code to change it as a post-install VI?

 

Cheers,

Martijn

 

PS This question is related to my earlier question about building shared libraries but I considered it sufficiently different to warrant a separate topic. Hopefully once this issue is solved I will be able to finish that procedure and update you all on the results.

[Martijn]

Further looking into this problem, it seems to occur whenever the CLN call as specified in the VI is invalid on the target machine at the time of install.

 

Simplest breaking case is a CLN referencing a 32-bit DLL. Install on LabVIEW 32-bit and the path resolves. Install on 64-bit LabVIEW and the path is the DLL in the original development directory but with a "." before the parent directory name.

 

In the case when platform independent *.* notation is used, any asterisks for platform independence are removed, leaving just an invalid DLL path as observed after installing on linux which somewhat surprised me above.

 

This seems like undesirable behaviour regarding packing CLNs when you're targeting multiple distributions - particularly if you want to compile the library on the target OS. I intend to use VI scripting to rename all the CLN calls after install, but I figure this behaviour should be documented somewhere.