unable to install oglib_lvzip v5.0.0-1 on Linux

[Zaphiro Technologies]

I can't install this package on Linux (even after uninstalling the previous version, 4.2.1b1)

I keep getting an error during the post-install :

 

I'm using VIPM 2017 and on Ubuntu I have to run it as root to make it work, I suspect that could the the issue.

[Zaphiro Technologies]

after re-writing the post-install VI in this way I could get the package to install

but then I have other issue with the clfn : dll on Linux doesn't go down too well

and when I try to select the lvzlib.so, LabVIEW complains that

[Zaphiro Technologies]

i manually extracted the lvzlib64.so from the ogp and replaced it in

/user.lib/_OpenG/lvzip

and renamed it to lvzlib.so

then re-selected it in all the clfns then it works...

[Jim Kring]

@Zaphiro Technologies

CC: @RolfK

There is a cross-platform shared library naming trick.  (It could be that the package build process messed up the paths when writing linker info.)

See: LabVIEW Help >> Configuring the Call Library Function Node

Quote

If you want to run applications or shared libraries created on different platforms, use the * wildcard to make the reference to the shared library platform independent. Use * for the file extension and * or ** to the left of the file extension, depending on how you name 32-bit and 64-bit libraries.

The following example illustrates how to use the * wildcard.

Example  -->   Translation

• myshared.*   -->   LabVIEW replaces the reference with the appropriate file extension to match the platform that is running the Call Library Node, for example, myshared.dll, myshared.so, and myshared.framework.
• myshared*.*   -->   LabVIEW replaces the reference with myshared32.* on 32-bit platforms and myshared64.* on 64-bit platforms. You can place the * anywhere to the left of the file extension. For example, my*shared.* can translate to my32shared.*. LabVIEW replaces .* with the appropriate file extension.
• myshared**.*   -->   LabVIEW replaces the reference with myshared.* on 32-bit platforms and myshared_64.* on 64-bit platforms. You can place the ** anywhere to the left of the file extension. For example, my**shared.* can translate to my_64shared.*. LabVIEW replaces .* with the appropriate file extension.

[Zaphiro Technologies]

in 4.2.1b1 the lib path was '/usr/local/natinst/LabVIEW-2020-64/user.lib/_OpenG.lib/lvzip/lvzlib.*' for all CLFNs

also another issue, that I also see on Windows as well as Linux is that the LVZip sub-palette is not showing up in the OpenG palette

[Rolf Kalbermatter]

2 hours ago, Jim Kring said:

@Zaphiro Technologies

CC: @RolfK

There is a cross-platform shared library naming trick.  (It could be that the package build process messed up the paths when writing linker info.)

See: LabVIEW Help >> Configuring the Call Library Function Node

Yes, I had until recently always build everything in LabVIEW 7.0 and had apparently in a long ago past patched the OpenG DEAB functions to not bork those shared library names (as I carefully made sure to use this trick in the source code version in every single VI). But because of a complete reinstallation of my Linux Virtual Machines I also had to move to a LabVIEW 8.6 installation for testing, I had preferred 2009 but could not find a Linux installer for that, and I had completely missed that the default OpenG DEAB seems to rewrite the linker information with fully explicit shared library name.

[Rolf Kalbermatter]

I uploaded a new version 5.0.1.0-1 which should address this installation issues on Linux.