Rolf Kalbermatter

Hmm, I assume you also use VIPM 2024 or whatever is shipped with LabVIEW 2024? I haven't tried to install with that yet, but it would seem there is some sort of regression here. Someone obviously is relinking the DLL path to "<userlib>:\source\lvzlib.dll" and that was not me when building the package which actually is referencing my own build path on my virtual machine at "Z:\openg-lvzip\openg-lvzip\source\lvzlib.*". Unfortunately it seems almost impossible to change that path to something more correct during package build. Did you make sure to install 5.0.2.0? This should solve several possible problems during install. 5.0.1.0 should not be used as there were indeed some installation and linking problems in the package build.

The package is supposed to request a mass compile after installation which should fix this issue. However that second path in LabVIEW 2020 looks very weird. Seems that VIPM is somehow relinking those paths but not in a good way. I just did a test install on LabVIEW 2020 SP1 f1 32-bit and there is nothing like that present. I see that VIPM properly does initiate a mass compile after installation and when afterwards looking at the VI's the past for the DLL is correctly pointing at where the DLL is supposed to be with a (star as ending instead of dll, but that is the correct and intended way).

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

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

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

I uploaded a new version 5.0.1.0-1 which should address this and some other installation issues for Linux.

The font looks somewhat different to what I’m used. I’m this week out of the office and have no access to a computer but will look into it next week.

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.